[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#1107250, @andrew.w.kaylor wrote:

> The reason that I originally implemented this the way I did, mutating the strict nodes to their non-constrained equivalents, was that I thought it would require too much duplication in the .td files to implement all the pattern matching for the strict nodes. The original plan was to find some other way to communicate the "strict" state to the target after instruction selection, but I never found a way to do that.
>
> What you've done here seems reasonable to me. Obviously it still involves a lot of updates to the td files, but your approach to making that manageable going forward seems plausible. I really don't have the expertise in instruction selection to judge that completely, but this looks like a promising direction.


Thanks for looking at this!

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.

This would avoid the duplication of all the FP instructions into two classes, and instead just give them an additional operand.  I'm still looking into how to best implement this. (Some tablegen changes will likely be required as well.)

> I particularly like that you've introduced it as a way for targets to opt-in. I believe some targets are already modeling the FP status and control registers and may not need this. X86 isn't one of them, so I think we'll want to consider something like what you've done here.

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

(Of course, this should still be opt-in per target, not only to allow for a step-by-step transition to the new scheme, but also since some targets may not support strict IEEE semantics anyway ...)


Repository:
  rL LLVM

https://reviews.llvm.org/D45576