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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
