Re: type based aliasing again

[Marc Espie <espie AT quatramaran.ens.fr>]

In article <e629bdfd.250f2c9c@aol.com> you write:
>> It's certainly within a reasonable "umbrella" approach of having
>>  increasing optimization levels be about increasing reliance on
>>  the code strictly conforming to the pertinent standard, even its
>>  "tricky bits".
>>  
>>  The biggest problem I see with it right now is that we haven't
>>  exactly taken that "umbrella" approach in the past in a consistent
>>  way.

>And it may not be the most useful scheme either.  With gcc-2.96 we are back 
>to -Os being faster running most of the time than -O2 or -O3 on x86, with 
>-march=pentiumpro (if applicable) and now -ffast-math (when it doesn't break 
>the application) needed for best results.  We would want to continue the 
>ability to get strict-aliasing at -Os.   I suppose we have no say on the 
>peculiar in-lining scheme with glibc; apparently on at -O and -O2, unless 
>specifically turned off; always off at -Os even when it would save space.

You can always turn strict-aliasing on or off explicitly with
-fstrict-aliasing or -fno-strict-aliasing.

The only issue here is whether it should be turned on by default for -O#.

I'm not too fond of pgcc idea of -O4 -> -O9 turning on `unsafe' optimizations.
The pgcc guys can do what they want... after all, pgcc was touted as a 
very fast, highly experimental compiler. Whereas gcc is supposed to be stable.

Therefore, I don't believe moving -fstrict-aliasing to -O3 or -O4 is a 
good idea. It's an issue of whether we consider this optimization as
`safe' or `unsafe'.  In the first case, it's a -O2 trigger, probably -Os
as well, as it should decrease the code size. In the second case, I see
no reason to treat it differently from -ffast-math.