================
@@ -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:
Ah, I see. Can you explain the reasoning for the special-casing constrained FP
intrinsics? Isn't strictfp an FP environment that frontends can activate using
something like `#pragma STDC FENV_ACCESS ON`? If so, there are two choices:
1. The environment is turned on in the caller function, and we convert all
applicable FP intrinsics to their constrained variants in Clang, and give them
to LLVM. In this case, Clang's Builder has an inherent strictfp state that's
flipped on, and everything it will emit is strictfp, including non-intrinsic
calls. Yes, strictfp calls inhibit inlining, as it would lead to an incorrect
optimization?
2. The environment is turned off in the caller function, and Clang's Builder
has the strictfp state turned off, which means that we will never create
constrained variants or strictfp non-intrinsic calls. Sure, it can be turned on
in a non-intrinsic callee function, but the caller itself is unaffected, and
non-intrinsic callees can still be inlined in the caller?
https://github.com/llvm/llvm-project/pull/211769
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
