Page MenuHomePhabricator

[doc] Clarify constrained fcmps behavior
ClosedPublic

Authored by thopre on Thu, Apr 22, 5:21 AM.

Diff Detail

Event Timeline

thopre created this revision.Thu, Apr 22, 5:21 AM
thopre requested review of this revision.Thu, Apr 22, 5:21 AM
Herald added a project: Restricted Project. · View Herald TranscriptThu, Apr 22, 5:21 AM

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.

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 updated this revision to Diff 339615.Thu, Apr 22, 7:06 AM

Fix clarification

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?

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 accepted this revision.Fri, Apr 23, 3:21 AM

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.

This revision is now accepted and ready to land.Fri, Apr 23, 3:21 AM
This revision was automatically updated to reflect the committed changes.