[doc] Clarify constrained fcmps behavior

[uweigand]

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.

[thopre]

In D101053#2708365, @uweigand wrote:

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.

Oh I see, I guess it needs clarification even more then. I'll adapt the patch accordingly, thanks.

[thopre]

Fix clarification

[uweigand]

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?

[thopre]

In D101053#2709157, @uweigand wrote:

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.

[uweigand]

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.

llvm/docs/LangRef.rst

 - "``une``": yields ``true`` if either operand is a NAN or ``op1`` is
   not equal to ``op2``.
 - "``uno``": yields ``true`` if either operand is a NAN.
 
 The quiet comparison operation performed by
 '``llvm.experimental.constrained.fcmp``' will only raise an exception
 if either operand is a SNAN.  The signaling comparison operation
 performed by '``llvm.experimental.constrained.fcmps``' will raise an
-exception if either operand is a NAN (QNAN or SNAN).
+exception if either operand is a NAN (QNAN or SNAN). Such an exception
+does not preclude a result being produced (e.g. exception might only
+set a flag), therefore the distinction between ordered and unordered
+comparisons is also relevant for the
+'``llvm.experimental.constrained.fcmps``' intrinsic.
 
 '``llvm.experimental.constrained.fmuladd``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Syntax:
 """""""
 
 ::