Request for feedback : Use of "-Og" by default for Debug builds

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 17 02:14:19 MST 2014
As many of you will be aware, LPCXpresso v7.0 has introduced a new optimisation level -Og : "Optimize for Debug".

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#Optimize-Options

Our own use of this option so far has shown noticeable code size / performance improvements over the -O0 option used by default for Debug configuration builds by LPCXpresso currently, whilst still giving a very good source level view when debugging.

To make use of the -Og option, you currently have to manually modify the properties for your project(s).

Project -> Properties -> C/C++ Build -> Settings -> Tool Settings …
… -> MCU C Compiler -> Optimization -> Optimization Level

However we are now considering switching to using -Og by default for new projects. But before we do this, we would be very interested to see some feedback from the LPCXpresso user base.

So please let us know your experiences of using -Og.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by djlegge on Wed Mar 19 09:28:12 MST 2014
Thanks for the reply. Adding

-fno-if-conversion2

prevents the odd behaviour around the if statement as you say. Perhaps this should be included as part of -Og (if possible) ? I would think the debugger should never lead you to believe C code is being executed when it isn't (using default debugging settings).

The other things are not really an issue (for me at least) because it is not like the debugger is actively misleading you but I would think that the optimisations should be 'turned down' to have as little effect on the debugging experience as possible.

I'll carry on with -Og for the moment. I am appreciating the quicker download times due to reduced code size !

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Wed Mar 19 08:01:04 MST 2014
@djegge - Thank you for your feedback and test case.

Quote: djlegge

With -Og, this code appears to single step into both branches :

Thanks for your feedback. If you open the disassembly view you can see that this behaviour is being triggered because the the compiler is making use of the IF-THEN (IT) instruction block feature of Cortex-M3/M4 to implement a set of conditional instructions. Those instruction which fail the condition are effectively translated into NOPs.

I suspect that it might be possible to improve the debug information generated in some situations here. But you can turn off the use of conditional instructions in the compiler using the option:

-fno-if-conversion2

Depending on your code, you may find that this option also helps:

-fno-if-conversion

More information in the sections on -fif-conversion2 / -fif-conversion at:
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html#Optimize-Options

I will follow this up with the GCC guys though.

Quote:

Now, carry on single stepping down to the while loop. Just as you get there, the code appears to jump up to the top of the function then back down again. Clearly this is just to initialise bytes_sent so no big deal.

Indeed. Initialise your local just before you first use it - rather than at the time of declaration (at the start of the function), and you will no longer see this behaviour.

Quote:

Now, in the while loop, mem_cpy() appears to get called once on it's own before the loop gets gets going properly. After the first iteration, single stepping works fine again.

I think the problem here is some of the setup code related to the memcpy() has been optimised so that it executes once before the while loop is entered, rather than every run through the while loop. Note that the call to memcpy() is not being executed an extra time here.

Regards,
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by djlegge on Wed Mar 19 05:20:09 MST 2014
Using the -Og option some more, I am noticing some weirdness when single stepping.
I have attached a simple project that runs on an LPCXpressoLPC1768 board. I am using linux.
Set a breakpoint on the call to get_can_from_log().
I have simplified the code down to some extent so it's not really doing anything useful but single step through get_can_from_log().
With -Og, this code appears to single step into both branches :

if (seq_number > rx_msg_sequence) {
// Code below single step witn -Og appears to step into both branches...
if ((seq_number + 5) < 10)
seq_number += RX_MSG_STORE_SIZE;
else
seq_number = oldest_sequence;
}

With -O0 it single steps as you would expect. In this case it would not matter if both branches were actually executed but it does the same if you change it to :

if ((seq_number + 5) < 10)
seq_number += RX_MSG_STORE_SIZE;
else
seq_number += oldest_sequence;

Now, carry on single stepping down to the while loop. Just as you get there, the code appears to jump up to the top of the function then back down again. Clearly this is just to initialise bytes_sent so no big deal.

Now, in the while loop, mem_cpy() appears to get called once on it's own before the loop gets gets going properly. After the first iteration, single stepping works fine again.

None of this is a big problem but it is at the least distracting when you are trying to debug...In my case, this would be enough to make me switch back to -O0.
Thanks for listening !

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 18 05:07:28 MST 2014

Quote:

What has changed now?

The -Og optimization level has been introduced for the first time in LPCXpresso.

Quote:

Have you tried it? Did you experience problems with it?

Yes, several hours. Debugging in Disassembly View. Result:
Quote:

It is best to always use -O0 for debugging.

We have asked for feedback. Can you please tell us what problems you found, preferably with an example that reproduces the problem. We have not experienced any problems, and it appears that the feedback from this forum is that the majority of respondents have not found a problem either.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Mar 18 04:58:37 MST 2014

Quote: alexgoldstone
You are quoting an LPCXpresso Support page that was written before the -Og option existed.

Yes, I know.

Quote:
When optimization is enabled, it will reorder code to improve performance. Changes like these might make the code confusing to debug. It is best to always use -O0 for debugging.

What has changed now?

Quote: alexgoldstone
Have you tried it? Did you experience problems with it?

Yes, several hours. Debugging in Disassembly View. Result:

Quote:
It is best to always use -O0 for debugging.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by alexgoldstone on Tue Mar 18 04:37:29 MST 2014
You are quoting an LPCXpresso Support page that was written before the -Og option existed.

-Og is intended to enable optimizations that do not interfere with debugging.

Have you tried it? Did you experience problems with it?

As previously noted, we have not seen any issues running and debugging with -Og.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Mar 18 04:20:55 MST 2014

Quote: alexgoldstone
The GCC documentation[1] all but recommends the use of -Og for Debug configurations.

:quest:

Quote:
Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you expect from the source code.

Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Not sure what their ' standard edit-compile-debug cycle' is, but obviously a simple or no debugging.

Do you like -Og debugging? Do you debug at all?

lpcxpresso-support is recommending no optimization :)

http://www.lpcware.com/content/project/nxp-peripherals/usb-nxp-microcontrollers/lpcxpresso-support

Quote:
When optimization is enabled, it will reorder code to improve performance. Changes like these might make the code confusing to debug. It is best to always use -O0 for debugging.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by alexgoldstone on Tue Mar 18 03:55:07 MST 2014
The GCC documentation[1] all but recommends the use of -Og for Debug configurations.

Quote:
-Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

When LPCXpresso 7.0.2 was released last week we set the Debug config for all existing projects to -Og and, although it has not been very long, so far we have not noticed any issues running and debugging. The size of debug builds is reduced considerably and this is a big win when developing for resource constrained micros such as the LPC800.

[1] http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

lpcware · ‎06-15-2016

Content originally posted in LPCWare by R2D2 on Tue Mar 18 02:55:09 MST 2014

Quote: lpcxpresso-support
This "single build config development cycle" is exactly the circumstance that the -Og option was designed for.

And that's the main question:

'Single Build Config Development'?

And the answer is YES. And this decision is obviously made already. So what are we discussing about? Pros and cons?

Of course it's easy and beginners don't need to understand all this difficult old-fashioned stuff.
And debugging is still possible (somehow).

Probably many users are beginners, so this Single Config question is more a general question: who is using LPCXpresso?

As mentioned already: professionals can (and I hope they do) switch back to O0 for a 2 Build Config. But I guess most of LPCXpresso users don't do that. Therefore I think my opinion is more or less worthless:

I'm using 3 different Configs:

1. Software Start: O0 - Writing new software, debug and test it
2. Test: O1 - Testing Hardware & Software
3. Release : O2 or Os

Also I use a lot of function and PRAGMA optimization. That's of course confusing.
So I think your decision to default Og as simple Single Build Config was correct...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by lpcxpresso-support on Tue Mar 18 01:21:06 MST 2014
Thank you for the replies received so far.

We have obviously done a lot of testing internally of the -Og option. But we felt that the change we are intending to make here, meant that it was worth getting some wider input on the experiences of users with their own code bases - both for the code generated in comparison to the current default -O0, and also in the debuggability of the code.

Our reasoning behind proposing this change to -Og is that a fair proportion of the user base that we talk to are aiming to develop, debug and release exactly the same build of their project, rather than switching between the traditional Eclipse "Debug" and "Release" build configurations at different stages of their project. This means that they have to either stay with -O0 and have none-optimised code (with the consequent overhead on performance and flash requirements), or turn up the optimisation level and encounter debugging oddities (as described in http://www.lpcware.com/content/faq/lpcxpresso/compiler-optimization).

This "single build config development cycle" is exactly the circumstance that the -Og option was designed for.

Another advantage that this will have is that for user who do use the "two build config development cycle", having -Og as the default for debug builds will help to avoid issues that are commonly found today when switching the Debug to Release builds (things such as failure to use volatile, as described in the above FAQ).

@djlegge - In order to look into the issue you are seeing, we would need to actually see you code in more detail (preferably in compilable form), plus confirmation of which MCU you are targeting. I suggest that if you can provide more details, you should put them into a new forum thread - so as to keep this thread for general feedback on -Og.

@LabRat - Note that if/when we make this change, there is nothing to stop you switching particular projects back to using -O0 if you wish. It is just that a newly created project will default to using -Og for the debug build config.

Regards.
LPCXpresso Support

lpcware · ‎06-15-2016

Content originally posted in LPCWare by OldManVimes on Mon Mar 17 09:32:45 MST 2014
Given that the compiler builders deliver on their promises, I think switching to -Og is a good idea. However it makes sense to test this first. If you test this on all sample projects of an Embedded artists board in combination with a Cortex M0 and M3, then it is reasonable to expect this to work properly in the bulk of all environments. Since I hope you are already doing this type of testing before releasing a new version of the compiler, it should not create a lot of new work.

The problem mentioned by djlegge may show that the devil is in the details. Is that problem caused by different code or by timing issues or both?

My 2 cents

lpcware · ‎06-15-2016

Content originally posted in LPCWare by LabRat on Mon Mar 17 08:52:08 MST 2014

Quote: lpcxpresso-support
So please let us know your experiences of using -Og.

Quote:
O0
--
text   data    bss    dec
55212    184   8240 63636

O1 -24,02%
---------
text   data    bss    dec
41948    184   8240 50372

Og -23,68%
---------
text   data    bss    dec
42136    184   8240 50560

I'm not sure where the (exact) difference between Og and O1 is, but it's nearly the same code reduction...

Debugging is working without problems...

Quote: lpcxpresso-support
However we are now considering switching to using -Og by default for new projects. But before we do this, we would be very interested to see some feedback from the LPCXpresso user base.

Default for what? Debug build? No, thanks. I don't like to debug optimized code in Debug build...

lpcware · ‎06-15-2016

Content originally posted in LPCWare by djlegge on Mon Mar 17 03:23:41 MST 2014
I tried it and it seemed to work well at first, giving an approximate 20% code size reduction and debugging was still sensible.
I then ran into a problem with I2C which caused my code to hang reading a serial eeprom on startup. I am using CMSISv2p00 and quite often while debugging the code would get stuck in I2C_Start() at the line :

while (!(I2Cx->I2CONSET & I2C_I2CONSET_SI));

I am not sure if it is something I am doing wrong and I haven't had the time to delve into it yet. However, setting the CMSIS libray back to -O0 or -Os for the debug build prevents the problem.

For the moment, I am using -Os for the CMSIS libray and -Og for the rest of the project and it's debugging fine.