scanon added a comment. > Prior to this change contract was never generated in the case of in-statement > contraction only, instead clang was emitting llvm.fmuladd to inform the > backend that only those were eligible for contraction. From a correctness > perspective I think this was perfectly fine. > > Currently I don't see any logic to generate "blocking intrinsics" (I guess to > define a region around the instructions emitted for the given statement). > Until such mechanism is in place, I think that generating the contract > fast-math flag also for in-statement contraction is wrong because it breaks > the original program semantic.
This is exactly right. If we are going to have new in-statement optimizations, then we probably do need to add some blocking intrinsic (which would be elidable given suitable fast-math flags); the system of generating fmuladd works well for FMA contraction, but doesn't really generalize to other optimizations of this sort. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72841/new/ https://reviews.llvm.org/D72841 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
