I don't believe this change is correct. Note that even if an exception is raised, the instruction may still have a result (if exceptions are configured to only set a flag bit and not actually trap). This result will still be different for ordered vs. unordered comparisons.
The statement is now correct, but it's still not completely clear to me why it is necessary. All floating-point intrinsics may still produce a result in addition to raising an exception (if they do), so the definition of the result is always independent of the question what -if any- exceptions are raised. Why does this need to be called out here specifically?
Other constrained operation have meaning irregardless of whether a trap is produced for an exception: they limit the sort of optimisation that can be done with FP operation. The distinction between ordered and unordered for constrained fcmps AFAIK only makes sense if no trap happens. I can also add a general reminder that exception does not necessarily implies trap at the beginning of the constrained intrinsics section if it makes more sense but I think we should have something here *as well* because that's where it's important to remember it.
Said another way, realising my mistake that exception != trap I would not change any of the STRICTFP node lowering except for STRICT_FSETCCS.
B.t.w. even if the raised exception does cause an actual trap, the result of the instruction might _still_ be accessed. This is now of course platform-specific, but e.g. on Linux it is possible to inspect the result of the instruction in the trap handler if one is installed; it is also possible for the trap handler to resume execution so that the result may also still be used by the original code afterwards. In those cases, even if there is a trap, there would still be difference between fcmp and fcmps visible.
But in any case, I guess if this extra text clarifies things for you, it might also be helpful to others, so I certainly don't mind adding it.