Re: pragma GCC optimize prevents inlining

[David Brown <david@westcontrol.com>]

On 04/01/2024 17:55, Segher Boessenkool wrote:
> On Thu, Jan 04, 2024 at 04:24:20PM +0100, David Brown via Gcc-help wrote:
>> In my case, I wrote it in that second version!  But had "-fwrapv" worked
>> through inlining, it would have been convenient and neat, especially as
>> I had several related functions (for a wrapping-integer class).
> 
> Most things work on function basis; almost nothing works per RTL
> instruction.  There is no per-instruction representation for -fwrapv
> in the RTL stream.
> 

Yes, I appreciate that.  And I can also imagine that carrying such 
option information in the AST to make this possible would be a 
significant burden, and very rarely of benefit - so unless there is some 
other important use-case then it is not a good trade-off.

> Things are even worse for -O2 vs. -O3 etc.
> 
>> More generally, I think the expected semantics are that the additional
>> options apply to code inside the function, and at the boundary you don't
>> care which set of options apply.  So if you have normal floating point
>> code that sets "x", and then call an inline function with -ffast-math
>> using "x" as a parameter and returning "y", then the inlined could can
>> assume "x" is finite and not a NaN, and the later code can assume the
>> returned value "y" is similarly finite.  If the calculations for "x"
>> produce a NaN, then the code will be UB - that's the programmer's fault.
> 
> Yes, but that is only true for -ffast-math (which means "the user does
> not care about correct results" anyway).

(Getting a little off-topic...

Um, that's not what "-ffast-math" means.  It means "the user is using 
floating point as a close approximation to real number arithmetic, and 
promises to stick to numerically stable calculations".  All my uses of 
floating point are done with "-ffast-math", and I /do/ care that the 
results are correct.  But the definition of "correct" for my work is "as 
close to the theoretical real number result as you can get with a 
limited accuracy format, plus or minus small rounding errors".

For other people, full IEEE compliance, support for NaNs, and 
bit-perfect repeatable results regardless of optimisations and target 
details, are important for correctness.  And that's fine, and it's great 
that gcc supports both kinds of code - though I believe that 
"-ffast-math" would actually be more appropriate for a large proportion 
of programs.)

> 
> You would not typically want random nearby code to use -fwrapv as well,
> for example.
> 

No, not normally.  (Some people would like C to work that way, but not me!)

> 
> Segher
>