4.8.2 -Og vs. -O1

[gds]

On 07/01/2013 02:05 AM, Joel Sherrill wrote:
> Have you compared it to -Os?  That seems to produce assembly closer to
what you would likely write by hand. I haven't benchmarked it much but it
gives 7-10% smaller code in general. In many cases, fewer instructions is
also a performance win.

Hi Joel,
Looking for every var and c/c++ instruction line visible and step-able 
in debugger with fastest possible code. A difficult trade-off no doubt.

Currently this only happens at -O0 but speed is really bad.

I haven't seen any other feedback on this list about the new -Og option.

-gene


>
> Gene Smith<gds@chartertn.net>  wrote:
>
>
> I tried -Og optimization on a recent svn snapshot of 4.8 and don't see
> much difference in the code compared to -O1. If anything, at least for
> one case, -Og is actually less debuggable than -O1, e.g., for a simple
> buffer selection like this:
>
> uint8_t* buffer;
>
> if (condx == true)
>          buffer = buf1;  // buf1 is a static external buffer
> else
>          buffer = buf2;  // buf2 is a static external buffer
> uint8_t foo = buffer[1];
>
> With -O1 there is assembly code associated with each buffer assignment
> statement. But with -Og there is no code under the first buffer = buf1
> with it all under the 2nd buffer = buf2.
>
> So, with -Og, when stepping through the code with condx true, it appears
> that the wrong line is executing since the first buffer = buf1 has no
> code and never occurs. Of course, the result is still correct and is
> actually maybe more efficient or at least equal to the -O1 code, but
> there is no improved debug experience in this case.
>
> In this case, the debug experience with -O1 is closer to -O0 than -Og is.
>
> Also with -Og, some variables are still optimized away like -O1 and
> higher, but unlike -O0 where all variables are, of course, visible with
> the debugger (gdb).
>
> -gene
>
>
>
>