Skip to content

Conversation

@JackNewman12
Copy link
Contributor

This works for me and it makes the UI feel a little snappier (could be placebo, not sure if the UI is firmware or screen hardware limited).

If I have a large number of local changes or custom images I find the firmware won't fit in memory with O3. I've made it O2 for now to save any future headaches from new features.

This works for me and it makes the UI feel a little snappier (could be placebo, not sure if the UI is firmware or screen hardware limited). 

If I have a large number of local changes or custom images I find the firmware won't fit in memory with O3. I've made it O2 for now to save any future headaches from new features.
@Xenoamor
Copy link
Contributor

That's interesting. The optimisation level is currently set here. I wonder if this is taking precedence over it
It would be great to use O3, hopefully they get round to fixing the flto bug

@JackNewman12
Copy link
Contributor Author

Good catch. Can't believe I didn't check that makefile. The -O2 I added gets appended after -Os in libopencm3.rules.mk

From the GCC manpage:

If you use multiple -O options, with or without level numbers, the last such option is the one that is effective.

I will move my changes when I get home.

@Xenoamor
Copy link
Contributor

If you move them then dpsboot will be compiled with it as well. It might make more sense where it currently is

@kanflo
Copy link
Owner

kanflo commented Oct 10, 2019

As soon as you move your changes @JackNewman12 I will merge this.

@Xenoamor
Copy link
Contributor

Xenoamor commented Oct 10, 2019

We'll want to keep the bootloader as -Os I think. Give us the most FLASH we can for the application. The application as -O3 makes sense though if we can afford it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants