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

[Zixuan Wu via Phabricator via llvm-commits]

wuzish added a comment.

In D45576#1410287 <https://reviews.llvm.org/D45576#1410287>, @uweigand wrote:

> 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.


OK. If we use tablegen multiclass to define two kinds of instructions is not too much work because of multiclass. One for strict fp pattern and one for normal non-strict although they will be mapped to same instruction in some targets but with different flags(one has hasSideEffect flag, one hasn't) or phys reg def/use?


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

https://reviews.llvm.org/D45576