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

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

In https://reviews.llvm.org/D45576#1108112, @hfinkel wrote:

> In https://reviews.llvm.org/D45576#1107985, @uweigand wrote:
>
> > Following the BoF at EuroLLVM, I've been talking to Chris Lattner about this, and he suggested a somewhat different approach: providing a way for an MI instruction to have the "unmodeled side effects" flag be provided by an MI *operand*.   That is, right now the hasSideEffects flag is a constant: any particular MI instruction class has this either set or clear, but to model FP instructions, it might be better to have a setting where whether or not any particular instantiation of the instruction has side effects depends on the value of an operand.
>
>
> But that's much stronger than necessary, and will prevent all kinds of optimizations. I don't think that we want to do that. Why not just add a dependence on the registers that matter?


So the above statement was assuming that you need hasSideEffects on the MI level to correctly model **certain** strict FP effects, specifically the mode where FP instructions may trap.   I agree that hasSideEffects is unneeded if we only want to model e.g. rounding modes or non-trapping exception flags.  But I don't really see how we can correctly model trapping instructions only by using register dependencies.

That's why my patch here uses multiclasses to provide two versions of all FP instructions, one with hasSideEffects set and one without.  The comment about using an operand to model side effects was meant in that context, to provide an easier way to achive the same effect without this duplication of instructions.

>> Can you elaborate which targets are already modeling the FP status flags?   This would be surprising to me, since actually modeling those for the current non-strict semantics would cause significantly worse code to be generated ...
> 
> I suppose that it depends on what you mean. The PowerPC backend, for example, as an RM pseduo-register to model the state of the current rounding mode. Moreover, we do model use dependencies on RM on calls and FP instructions. I think that all we need to do is add defs of RM (and likely rename RM to represent some more-general status).

I see.  For just modeling the rounding mode, the current PowerPC implementation actually looks fine to me, since this will not introduce many unnecessary scheduling constraints.  (The FP instructions are only users of the RM register, and the only defs are the intrinsics -- and in the future probably any call within a  FENV_ACCESS region, but that can be handled like a variant calling convention.)

But extending that model to non-trapping exception status flags will introduce significant constraints: basically every FP instruction will have to both use and def the register, in effect creating a totally ordered chain of all FP instructions that prevents any reordering.  I do not think you'll want that active by default ...   And as to the trapping exception mode, as mentioned above, I don't believe just register dependencies are enough.


Repository:
  rL LLVM

https://reviews.llvm.org/D45576