[PATCH] D136786: Fix `unsafe-fp-math` attribute emission.

Mon Oct 31 10:10:04 PDT 2022

andrew.w.kaylor added a comment.

In D136786#3893559 <https://reviews.llvm.org/D136786#3893559>, @michele.scandale wrote:

> The fact that `"unsafe-fp-math"="true"` implies `-ffp-contract=fast` is quite unfortunate, and it is something that in principle should be addressed.
> My understanding is that the floating point math function attributes are a quite old concept that predates the per-instruction fast-math flags. Ideally we should get rid of the flooding point math function attribute since we do have a finer grain representation.
> A while back the main issue was that all the backends code (e.g. DAGCombiner) were only using the `TargetOptions` properties (hence the function attributes) to control the floating point related transformations, hence there would have been regressions.

Yes, the function attributes are a vestige of the time before the fast-math flags were introduced, but the use of them hasn't been entirely eliminated and I think there are a couple of cases where some people think it's necessary. I posted an RFC and a patch about a year ago to start cleaning this up, but I got pulled away before it landed and honestly I had forgotten about it. https://discourse.llvm.org/t/rfc-eliminating-non-ir-floating-point-controls-in-the-selection-dag/59173

> At high level, I think that we need to understand how important is to match GCC behavior in this particular case. We can change the way Clang defines `-funsafe-math-optimizations` to imply `-ffp-contract=fast`, but that seems the wrong solution as it feels like promoting a bug to a feature.

I wouldn't consider the fact that unsafe-fp-math (as a concept) implies fp-contract=fast to be a bug. Yes, it may appear to deviate from the gcc behavior, but the reasons for that are complicated. Mostly they stem from the fact that gcc doesn't support fp-contract in the way that the C standard describes it.  In gcc, fp-contract is fast or off, and it defaults to fast. If you pass -ffp-contract=on to gcc, it behaves exactly like -ffp-contract=off. If you pass -std=c99, the default for fp-contract changes to on, but because gcc doesn't support fp-contract=on, FMA isn't formed. https://godbolt.org/z/K86Kv8W7h

My take on this is that fp-contract=on is a mode that conforms to the language standard and fp-contract=fast allows value changing optimizations that do not conform to the standard. Value-changing optimizations that do not conform to the standard are exactly what the definition of -funsafe-math-optimizations allow, so I can't see any reason that -funsafe-math-optimizations shouldn't imply fp-contract=fast.

So I was going to say that gcc is wrong, even by its own rules, to not allow fp-contract=fast behavior under -funsafe-math-optimizations, but then I double-checked my understanding and made a very happy discovery ... -funsafe-math-optimizations DOES imply fp-contract=fast in gcc! You just need to follow a convoluted path to see that (i.e. change the default to something other than fast using -std=c99 and then add the unsafe math option). https://godbolt.org/z/K1GonvGdT

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136786/new/

https://reviews.llvm.org/D136786