Odd optimizer behavior with FP arithmetic

[Alexander Monakov]

On Thu, 26 Sep 2019, Konstantin Shegunov wrote:

> Hello,
> I have a piece of floating point EFT arithmetic in my code, but I get a
> rather strange code generation for it. Here's the actual source code and
> flags I've experimented with: https://godbolt.org/z/oJEs4U
> 
> The first pane is what I expect to get as output, that is, all the
> arithmetic operations in the assembly. However the strange thing is I have
> to compile with -funsafe-math-optimizations to actually produce that.
> The second pane is the same thing but with -fno-unsafe-math-optimizations
> (default) and surprisingly the optimizer strips the relevant instructions.

The 'add' function is inlined into main, and floating-point operations that
would compute result.c are eliminated as dead code because result.c is never
used.

(and because the compiler doesn't attempt to preserve floating-point exceptions
that those eliminated instructions might raise)

> I would've thought the -fno-associative-math enough to prevent that from
> happening but for some reason it's not.
> The third pane I added for good measure. It illustrates the same flags as
> the first one (the one that generates the correct assembly), but the flags
> are applied through an attribute directly to the symbol. Even more
> surprisingly this generates yet another completely different piece of
> output, which doesn't even seem to do what's supposed to (unsafe means
> unsafe in this case, I gather).

In this case inlining does not happen due to flags being different between
'main' and 'add'.

In the first case inlining also does not happen for the same reason.

Alexander