Speculative FP operation.

Hi all,

We have a situation ,where the floating operations were hoisted
speculative from a conditional block on ARM64.

Was using the option "-mllvm --speculate-fp-insts=false" but doesn't
have any effect from LLVM 12 .

and "-ftrapping-math" is not enabled for aarch64 .

So question to the expert ,while investigating the passes we found
that simplifyCFG does this transformation and before we investigate
and prevent this transformation .

Do the group recommend any other options here ?

Thank you
~Umesh

Hi All,

Did someone tried enabling the trapping math for the aarch64 arch ?
So that we can surpass the transformation like below.

If not ,we would like to take it up for ARM arch.

Thank you
~Umesh

Hi,

Hi All,

Did someone tried enabling the trapping math for the aarch64 arch ?
So that we can surpass the transformation like below.

As far as I know, initial trapping math support only existing for X86 at the moment.

If not ,we would like to take it up for ARM arch.

I am not aware of anybody working on trapping math for AArch64, so any work in this area could be very valuable. I am CC’ing a couple of people who might know more about the current state of trapping math in Clang.

Cheers,
Florian

I’m currently working on AArch64 strict fp support (which is what’s needed to enable -ftrapping-math).
There’s a few patches currently in review:
https://reviews.llvm.org/D114946

https://reviews.llvm.org/D115352 (though I need to rebase this)

https://reviews.llvm.org/D115620 (needs some extra work to enable a currently xfailed test)

And I’m working on some other patches:
Miscellaneous fixes for vector instruction lowering
Model FPCR use in AArch64 instructions
Fixes related to GlobalISel (not strictly needed as GlobalISel falls back to default isel when it can’t handle things)

Once all of the above is done I think that I can then mark AArch64 as supporting strict fp in clang, so that -ftrapping-math isn’t ignored.

John

X86, PowerPC, SystemZ.

I believe PowerPC is the only target that properly handles dynamic rounding
mode, where instructions don't get moved past a call instruction since we
don't know if the rounding mode will be changed. I might have missed the
fix for the other targets, though.

That’s great news, thanks for pushing on this!

Cheers,
Florian