Optimization Flags: Best Practices?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In general, is it better to develop with or without compiler optimization (-O1, etc.) enabled?

 

Some of my code is time-sensitive (i.e. driving a pin high or low for a specific length of time). With optimization disabled, I can completely control the timing by manually optimizing critical pieces, but it seems like this could reduce the clarity (and portability) of code if I replace a nicely abstracted pin function (ioport_set_pin_level(...)) with a low level register command (PIOA->PIO_SODR = 0x00200000) to avoid the overhead.

 

I'm a newbie to embedded C programming, so I wasn't sure if there was a "best-practice" regarding use of the optimization flags (-O0, -O1, -Og, etc...) on the compiler...

This topic has a solution.
Last Edited: Wed. Nov 16, 2016 - 02:43 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never, ever, ever use -O0. It is simply there as a test mode for the compiler developers so they can see the dreadful code that is fed into the optimiser. Loads of things (timed stuff) won't work if you build -O0 because the code is so slow and bloated it won't meet the timing requirements.

 

If you pick -O0 to debug because "it's easy" then you will end up debugging something that is quite unlike the -O1..3/s that you eventually release.

 

AS7 (since I told them back at the AS5 stage) now uses -O1 (not -O0) for "Debug" and -Os for "Release", these are probably sensible choices until -Og is more easily available as a choice for "Debug".

 

Of course the final release choice between -Os and -O3 kind of depends on the way in which you want it optimised (size or speed). User manual here:

 

https://gcc.gnu.org/onlinedocs/g...

 

As you'll read there the -On/-Os choices are really nothing more than a grouping of 10's of -fxxxx options, so if you want even more control you could build your own optimisation by some combination of -Ox and -fxxx selections. Though that's probably for "power users". The 123s choices are sensible groupings for most. Just go with -O3 for speed, -Os for size as a starting point.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gotcha. Thanks for the insight--it really helps.

 

Regarding -Og, is it possible to use this mode by setting "None (-O0)" from the drop down in Atmel, then manually adding -Og under "Other optimization flags"? I've tried this, and it seems to work, but I don't want to be inadvertently causing issues.

 

If so, does this mode indeed improve debugging in any meaningful sense compared to developing on say -O1? The attached link didn't go into a whole lot of detail on the -Og flag, but it sounds like a nice compromise...(?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ucbuyer77 wrote:
Regarding -Og, is it possible to use this mode by setting "None (-O0)" from the drop down in Atmel, then manually adding -Og under "Other optimization flags"? I've tried this, and it seems to work, but I don't want to be inadvertently causing issues.
In the short term I don't see any other way. I think this is going to lead to a compiler invocation like:

avr-gcc -c -O0 -mmcu=atmega16 -fstruct-pack etc etc -Og foo.c -o foo.o

where two different ones are passed on the command line. Hopefully the last one listed "wins" (you can probably tell that by studying the generated Asm code!).

 

One day Atmel will modify the actual IDE to add a -Og option to the drop list.

ucbuyer77 wrote:
If so, does this mode indeed improve debugging in any meaningful sense compared to developing on say -O1?
That remains to be seen as virtually no one is using -Og right onw for the reason that the IDE doesn't offer it. Anything "new" in GCC is almost certainly there for ARM or x86/x64 users not us humble AVR users so it could be that -Og for AVR is actually no different to -O1 at all - only time will tell.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Makes sense. FWIW, the link you posted does mention:

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

Anyways, thanks for the perspective and help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And remember that they are all just a group of compiler flags that make different optimizations, but it if you want you can control those individually.

 

https://gcc.gnu.org/onlinedocs/g...  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Adding -Og is on the list. However last time I looked into it, I decided to not add it since it was 'broken' for arm (there's a gcc mail thread somewhere on it) and avr-gcc wasn't on gcc 4.9 yet. 

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of my code is time-sensitive (i.e. driving a pin high or low for a specific length of time). With optimization disabled, I can completely control the timing by manually optimizing critical pieces

Can you use a timer, rather than relying on your code to "set" the timing? Unless you are trying to make extremely fast pulses, this is probably more stable than counting loops & such & relying on a particular optimization to happen (or not happen).  Of course timers & IRQ's create "jitter"  due to their resolution and/or latency in responding.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, I recently discovered that while "-Os" does pretty much the same things as "-O" on AVRs, that does NOT seem to be the case for ARM.  (either that, or the ARM is much more accurate and aggressive at achieving "smaller" than the AVR.)

http://forum.arduino.cc/index.ph... (CM3 -O1 code is 3% bigger and 500% faster...)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Man, I'm getting old. I used to pour over every GCC (pre)release changelog and play with all the new features -- nowadays in my companies we have to stick with the compiler version that the products started with unless there's a roadblock, so I have been a bit lax. I had no idea that -Og was even a proposal, let alone released in GCC.

 

Morten: saves me harassing you via IM - what were the ARM bugs you noted?

 

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Dean not me, from Keil (in the gcc mailinglist, I'll try to dig it up). Due dilligence; this is over a year ago, so my info may be out of date..

 

(you always harass me on IM...)

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Meh, too much to read; it was in arm-gcc launchpad or on the gcc mailist smiley

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.