Say, in D80952 I added support for disabling strictfp support when a target doesn't support it. But it only applies to command line arguments.

In D87223#2265348, @qiucf wrote:

In D87223#2261086, @kpn wrote:

Over in D80952 there was a comment from @steven.zhang: "Agree that we can turn on it later when it is done." But your comment here is that it is "almost done".

Is it fair to say that the PowerPC work is at _parity_ with X86 and SystemZ? I think that's a better cutover point than "done".

Yes, we've disabled the FP mutation in rG6afb2791. vector-constrained-fp-intrinsics.ll is also aligned with X86 & SystemZ.

Over in D80952 there was a comment from @steven.zhang: "Agree that we can turn on it later when it is done." But your comment here is that it is "almost done".

It would be better to go with D85960. I'll hedge and keep this open until that one gets pushed.

You mentioned in D85920 a need to merge this review with that review. I don't think that's needed. This code here is farther along. It does everything that D85920 does and has necessary pieces implemented as well.

Thanks for the reviews and the fast turnaround! I do appreciate it!

Add the -fexperimental-strict-floating-point flag to enable on hosts that are not marked as supporting strict FP yet. Add test and documentation.

Already on it. I hope I got it now.

Ping. I'm really hoping to get this into 11. Otherwise we're going multiple releases with options that people already use causing crashes on most architectures.

Remove debugging command left in accidentally. Rebase.

Ping?

Ping.

Added new warnings to a new group "unsupported-floating-point-opt". The warning can be disabled. The disabling of constrained floating point is unaffected by the status of the warning.

In D80952#2067643, @arsenm wrote:

In D80952#2067563, @efriedma wrote:

The problem for the command-line arguments in particular is that they aren't really new; clang has been eating them for a long time, without any warning. So if -frounding-math crashes the compiler, that's a regression.

Could we get an -fexperimental-something flag to override this behavior then?

This currently triggers a failure in test "Clang :: Misc/warning-flags.c". Suggestions on how to fix that correctly are welcome.

Update to not "upgrade" the strictfp attribute on a call to a constrained FP intrinsic. When my IR verifier changes land it will result in a misleading error message.

Address review comments.

Address review comments, and add a test to verify the additional code.

Commandeering with Andy's permission.

Most of this is in TableGen files, and I have so little experience there that I can't review. I'm sorry.

In D74729#2008093, @sepavloff wrote:

In D74729#2005958, @kpn wrote:

I think we need to be clear in the documentation that this is _not_ a substitute for the constrained FP intrinsics. Can you please add that to your new documentation? Include a link to the "Floating-Point Environment" section in the language ref.

It cannot be such substitute. IIUC constrained intrinsics were introduced to represent variants of corresponding C functions that operate in non-default FP environment to distinguish them from "ordinary" variants, that are pure functions. Functions like set_rounding always access FP environment, it always have side effect and must be properly ordered.

I think we need to be clear in the documentation that this is _not_ a substitute for the constrained FP intrinsics. Can you please add that to your new documentation? Include a link to the "Floating-Point Environment" section in the language ref.

In D74729#2005862, @arsenm wrote:

In D74729#2005777, @kpn wrote:

Are there GPUs or AI cores _targeted by llvm_ that support changing the rounding mode at run-time?

AMDGPU can

Are there GPUs or AI cores _targeted by llvm_ that support changing the rounding mode at run-time?

Update from review comments. The new emitCallMaybeConstrainedFPBuiltin() function does make the code much cleaner.

Didn't Andy Kaylor have a plan to pass strict FP metadata through using (I think he called it) bundles?

I ran a check myself. I found that there are quite a few existing tests that enter BitcodeReader::materialize() from someplace other than BitcodeReader::materializeModule(). Perhaps one of these would be helpful in coming up with a new test?

Note that the AArch64 backend isn't ready for some of these changes. That's why the test is marked XFAIL.

It looks like a whole bunch of instructions got converted into simple loads. Which is exactly what was expected.

In D72930#1946234, @sepavloff wrote:

In D72685#1868618, @lkail wrote:

Correct me if I'm wrong. rint(x) returns x if x is an NaN. However, intruction like XSRDPIC may turn SNAN to QNAN. Does it matter?

Address review comments: FMA tests are now run optimized. This changes where the FIXME lines are located.

In D73201#1834370, @craig.topper wrote:

We want to remove all the mutation code once the in tree targets all support STRICT_ nodes properly. It's a hack to enable targets to limp along a little bit, but in hindsight may have been a bad idea since it creates the illusion of things working when they really don't.

Eliminate a blank line I thought I had already had gotten.

Update for review comments.

Excellent! Thanks Matt!