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

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

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

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


If you'll go back to the beginning of this discussion, you'll note that this was in fact my very first approach to this problem.  I would have been fine with that for SystemZ, but there was pushback from other target maintainers that this would be a lot of work for all targets, and therefore I started looking into other options.


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

https://reviews.llvm.org/D45576