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

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 26 02:27:52 PST 2019


uweigand added a comment.

In D45576#1410273 <https://reviews.llvm.org/D45576#1410273>, @wuzish wrote:

> Well, I have a question about why is it not enough to use use/def of physical register in MI level to prevent the reordering of instructions about set/get fp status register? For example, If the instruction which setting rounding mode, and then the instruction which read the rounding mode, the sequence would not be reordered because of the dependency of rounding mode bits (fp status register).


This would be enough to handle rounding-mode aspects.  But if FP exceptions are enabled, we have additional restrictions: all FP exceptions could then have additional side effects (trap) and therefore cannot be executed speculatively, even where that would be OK from a status register dataflow perspective.

Also, one goal of the design is that we do **not** have to duplicate all FP instruction patterns in the back-end; we want a single pattern that can handle both the strict and non-strict case.  If we wanted to a phys reg def, that would then have to be optional in some form, and there's no good way I can see to do this in the current infrastructure.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D45576/new/

https://reviews.llvm.org/D45576





More information about the llvm-commits mailing list