[PATCH] D69281: [FPEnv] Constrained FCmp intrinsics

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D69281#1759817 <https://reviews.llvm.org/D69281#1759817>, @uweigand wrote:

> In the end, the reason why I chose to separate STRICT_FSETCC and STRICT_FSETCCS is that this makes it straightforward for the back-end to signal availability of the underlying instructions (which may be distinct).
>
> Specifically, on SystemZ we have quiet vector compare instructions in z13, but we only got the signaling vector compare instructions in z14.  This means on z13 we have to scalarize signaling (but not quiet) vector compares.  With two DAG opcodes, the back end only has to specify this like so:
>
>   setOperationAction(ISD::STRICT_FSETCC, VT, Custom);
>   if (Subtarget.hasVectorEnhancements1())
>     setOperationAction(ISD::STRICT_FSETCCS, VT, Custom);
>   
>
> and everything is just handled correctly automatically.
>
> Having just a single DAG opcode would make this more complicated.
>
> On the other hand, I found handling two opcodes in common code quite straightforward, usually simply adding another case statement to a switch.  Adding an extra argument to the DAGnode  (sort of like FP_ROUND) also need special code all over the place to handle ...


Just a thought if we merged signaling into the predicate, could we use the setCondCodeAction(might have the name wrong). On X86 for vectors we have signaling on qnan for LT/LE/GT/GE, but eq/ne/ord/unord only signal on snan. At least prior to AVX. Of course since it’s X86 we probably need custom handling for other reasons so maybe it doesn’t matter.


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

https://reviews.llvm.org/D69281