GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation

GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation

[Moritz Strübe]

Hi,

I have an issue with the optimization options. We are on an stm32 and it 
only has a prefetcher, but no cache. Thus it's nice to have linear 
default path. For example, we use  __builtin_expect in our asserts. Yet 
it seems that this does not work when using -Os. I confirmed that this 
is not an arm issue, but can also be seen on x86.
I have the following code:
----------
#include <stdint.h>
#ifdef UN
#define UNLIKELY(x)     __builtin_expect((x),0)
#else
#define UNLIKELY(x) (x)
#endif

float a = 66;

int test (float b, int test) {
     if(UNLIKELY(test)) {
         return b / a;
     } else {
         return b * a;
     }
}
----------
"gcc -O2" reorders the code depending on a passed -DUN, while -Os always 
produces the same output (see https://godbolt.org/z/cL-Pbg)

I played around with different options running
gcc -O{s|2} -Q  --help=optimizers
, but didn't manage to get -Os to do that optimization.
Opposed to what the manual[1] says, this only differs in 
-finline-functions and -foptimize-strlen for 8.3
(OT: Especially the info about freorder-blocks-algorithm seems to be 
outdated for gcc 8.3 (my arm 7.3.1 produces smaller code using stc, too).)
Since adjusting all those options didn't help I tried
gcc -O{s|2} -Q  --help={param|common|target|c++}
but that didn't give me any new insight. (BTW: "-Q --help=param" should 
probably be documented in the --param-section)

Cheers
Moritz


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

-- 
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

Re: GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation

[Martin Liška]

On 3/25/19 1:36 PM, Moritz Strübe wrote:
> Hi,
> 
> I have an issue with the optimization options. We are on an stm32 and it 
> only has a prefetcher, but no cache. Thus it's nice to have linear 
> default path. For example, we use  __builtin_expect in our asserts. Yet 
> it seems that this does not work when using -Os. I confirmed that this 
> is not an arm issue, but can also be seen on x86.
> I have the following code:
> ----------
> #include <stdint.h>
> #ifdef UN
> #define UNLIKELY(x)     __builtin_expect((x),0)
> #else
> #define UNLIKELY(x) (x)
> #endif
> 
> float a = 66;
> 
> int test (float b, int test) {
>      if(UNLIKELY(test)) {
>          return b / a;
>      } else {
>          return b * a;
>      }
> }
> ----------
> "gcc -O2" reorders the code depending on a passed -DUN, while -Os always 
> produces the same output (see https://godbolt.org/z/cL-Pbg)
> 
> I played around with different options running
> gcc -O{s|2} -Q  --help=optimizers
> , but didn't manage to get -Os to do that optimization.

Hi.

So first we have a misleading documentation for 8.3.0, you're hitting:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829

So with -Os we enable BB reordering, the only difference is that we set
-freorder-blocks-algorithm=simple with -Os. However, on x86_64, it stays
with -freorder-blocks-algorithm=stv.

Then you can use -fdump-rtl-bbro and see a dump file:
pr-expect.c.300r.bbro

The issues you're seeing is caused by fact that bbro uses
optimize_function_for_size_p functions that return true with -Os.
That's probably why you see the difference. That's my quick analysis.

Maybe Honza can help here?

Martin

> Opposed to what the manual[1] says, this only differs in 
> -finline-functions and -foptimize-strlen for 8.3
> (OT: Especially the info about freorder-blocks-algorithm seems to be 
> outdated for gcc 8.3 (my arm 7.3.1 produces smaller code using stc, too).)
> Since adjusting all those options didn't help I tried
> gcc -O{s|2} -Q  --help={param|common|target|c++}
> but that didn't give me any new insight. (BTW: "-Q --help=param" should 
> probably be documented in the --param-section)
> 
> Cheers
> Moritz
> 
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Optimize-Options.html
> 

__builtin_expect() reduces optimization (Was: GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation)

[Moritz Strübe]

Hey.

Am 25.03.2019 um 13:36 schrieb Moritz Strübe:
> I have the following code:
> ----------
> #include <stdint.h>
> #ifdef UN
> #define UNLIKELY(x)     __builtin_expect((x),0)
> #else
> #define UNLIKELY(x) (x)
> #endif
>
> float a = 66;
>
> int test (float b, int test) {
>       if(UNLIKELY(test)) {
>           return b / a;
>       } else {
>           return b * a;
>       }
> }
> ----------
> "gcc -O2" reorders the code depending on a passed -DUN, while -Os always
> produces the same output (seehttps://godbolt.org/z/cL-Pbg)

Actually that is wrong. I was diverted by looking for reorderings. When 
compiling with -Os -DUN there is an additional, and unnecessary, "movaps 
%xmm0, %xmm1". (I seen the same thing on arm, as it is more visible 
there: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1821703)

I also had a quick look at the output of -fdump-rtl-bbro, as suggested 
by Martin, but I'm afraid I'll need a week of digging into the specifics 
before I can interpret it.

Cheers
Morty


-- 
Redheads Ltd. Softwaredienstleistungen
Schillerstr. 14
90409 Nürnberg

Telefon: +49 (0)911 180778-50
E-Mail: moritz.struebe@redheads.de | Web: www.redheads.de

Geschäftsführer: Andreas Hanke
Sitz der Gesellschaft: Lauf
Amtsgericht Nürnberg HRB 22681
Ust-ID: DE 249436843

Re: GCC-Reordering-Optimization-Options in Os and O2 when using __builtin_expect() and documentation

[Richard Biener]

On Wed, Mar 27, 2019 at 1:27 PM Martin Liška <mliska@suse.cz> wrote:
>
> On 3/25/19 1:36 PM, Moritz Strübe wrote:
> > Hi,
> >
> > I have an issue with the optimization options. We are on an stm32 and it
> > only has a prefetcher, but no cache. Thus it's nice to have linear
> > default path. For example, we use  __builtin_expect in our asserts. Yet
> > it seems that this does not work when using -Os. I confirmed that this
> > is not an arm issue, but can also be seen on x86.
> > I have the following code:
> > ----------
> > #include <stdint.h>
> > #ifdef UN
> > #define UNLIKELY(x)     __builtin_expect((x),0)
> > #else
> > #define UNLIKELY(x) (x)
> > #endif
> >
> > float a = 66;
> >
> > int test (float b, int test) {
> >      if(UNLIKELY(test)) {
> >          return b / a;
> >      } else {
> >          return b * a;
> >      }
> > }
> > ----------
> > "gcc -O2" reorders the code depending on a passed -DUN, while -Os always
> > produces the same output (see https://godbolt.org/z/cL-Pbg)
> >
> > I played around with different options running
> > gcc -O{s|2} -Q  --help=optimizers
> > , but didn't manage to get -Os to do that optimization.
>
> Hi.
>
> So first we have a misleading documentation for 8.3.0, you're hitting:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829
>
> So with -Os we enable BB reordering, the only difference is that we set
> -freorder-blocks-algorithm=simple with -Os. However, on x86_64, it stays
> with -freorder-blocks-algorithm=stv.
>
> Then you can use -fdump-rtl-bbro and see a dump file:
> pr-expect.c.300r.bbro
>
> The issues you're seeing is caused by fact that bbro uses
> optimize_function_for_size_p functions that return true with -Os.
> That's probably why you see the difference. That's my quick analysis.

Yeah, I think it's use of optimize_function_for_size_p is at least odd.
It seems to be a defensive check in place to do as little as possible
keeping the original order.  I think the only thing that should be disabled
is tracing of cold paths.

But this is all stage1 material.

Richard.

> Maybe Honza can help here?
>
> Martin
>
> > Opposed to what the manual[1] says, this only differs in
> > -finline-functions and -foptimize-strlen for 8.3
> > (OT: Especially the info about freorder-blocks-algorithm seems to be
> > outdated for gcc 8.3 (my arm 7.3.1 produces smaller code using stc, too).)
> > Since adjusting all those options didn't help I tried
> > gcc -O{s|2} -Q  --help={param|common|target|c++}
> > but that didn't give me any new insight. (BTW: "-Q --help=param" should
> > probably be documented in the --param-section)
> >
> > Cheers
> > Moritz
> >
> >
> > [1] https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Optimize-Options.html
> >
>