[PATCH] D45576: [RFC] Allow target to handle STRICT floating-point nodes

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

This version now correctly implements target support for STRICT floating-point nodes using a MMO to represent the floating-point exception status.  (Note that targets can and should additionally use a register use dependency on *all* floating-point instructions to represent floating-point control state, e.g. rounding mode and exception trap flags.)

This is now handled mostly by target-independent code: the STRICT_ DAG nodes now count as MemIntrinsic nodes and carry the fp-status MMO right from the beginning.  This is now also using a new target-independent "fp-status" flavor of PseudoSourceValue.  The STRICT_ DAG nodes then go through DAG selection as usual, keeping their chain until the end.

As noted earlier, this currently requires the target to provide two DAG patterns when matching floating-point instructions, e.g. one for fadd and one for strict_fadd.  But those can now both resolve to the *same* MI instruction.  The resulting MI will be distinguished by either carrying or not carrying the fp-status MMO.

I haven't found any way to avoid having two patterns; it would be nice to have some sort of "alternative", like "match either fadd or strict_fadd here", but this doesn't appear to exist.

Special-casing strict FP nodes SelectionDAGISel::SelectCodeCommon seems a bit awkward, but is currently necessary because otherwise the fp-status MMO would not be transferred to the final MI, since it is *not* marked as mayLoad or mayStore in general (that was the whole point of this approach ...).

Any thoughts?


https://reviews.llvm.org/D45576