Odd optimizer behavior with FP arithmetic

Odd optimizer behavior with FP arithmetic

[Konstantin Shegunov]

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.
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).

Has anyone any insight into this?
Why isn't -fno-associative-math enough in stopping the optimizer here?
Why would -funsafe-math-optimizations actually trigger the correct code
being generated?
And as a curiosity, why would it matter if the flag is applied to the
symbol in contrast to the pragma?

Thanks in advance!
Konstantin.

Re: 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

Re: Odd optimizer behavior with FP arithmetic

[Konstantin Shegunov]

On Thu, Sep 26, 2019 at 8:11 PM Alexander Monakov <amonakov@ispras.ru>
wrote:

> 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)

...

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.
>

Well, ain't I a dummy.

Thanks a lot!
Konstantin.