[clang] [llvm] [mlir] [IR] Make semantics of strictfp consistent v2 (PR #211769)
Ramkumar Ramachandra via cfe-commits
cfe-commits at lists.llvm.org
Tue Aug 4 03:49:17 PDT 2026
================
@@ -2800,7 +2800,8 @@ fn -> other_fn -> other_fn ; fn is norecurse
optimizations that require assumptions about the floating-point rounding
mode or that might alter the state of floating-point status flags that
might otherwise be set or cleared by calling this function. LLVM will
- not introduce any new floating-point instructions that may trap.
+ not introduce any new floating-point instructions that may trap. All
+ function definitions that contain strictfp calls must be marked strictfp.
----------------
artagnon wrote:
Interesting, and I think I understand. I think the point of confusion for me is strictfp intrinsics that are not constrained FP intrinsics: wouldn't these be sensitive to FP optimizations? Would they be selected to a platform-specific FP opcode? The original motivation for the patch was actually https://github.com/llvm/llvm-project/pull/205061 -- can you kindly give feedback on canConstantFoldIntrinsic?
https://github.com/llvm/llvm-project/pull/211769
More information about the cfe-commits
mailing list