On Mon, Jun 07, 2021 at 05:31:50PM -0500, Segher Boessenkool wrote:
> On Tue, May 18, 2021 at 04:28:27PM -0400, Michael Meissner wrote:
> > In this patch, I simplified things compared to previous patches. Instead of
> > allowing any four of the modes to be used for the conditional move
> > comparison
> > and the move itself could use different modes, I restricted the conditional
> > move to just the same mode. I.e. you can do:
> >
> > _Float128 a, b, c, d, e, r;
> >
> > r = (a == b) ? c : d;
> >
> > But you can't do:
> >
> > _Float128 c, d, r;
> > double a, b;
> >
> > r = (a == b) ? c : d;
> >
> > or:
> >
> > _Float128 a, b;
> > double c, d, r;
> >
> > r = (a == b) ? c : d;
> >
> > This eliminates a lot of the complexity of the code, because you don't have
> > to
> > worry about the sizes being different, and the IEEE 128-bit types being
> > restricted to Altivec registers, while the SF/DF modes can use any VSX
> > register.
>
> You do not have to worry about that anyway. You can just reuse the
> existing rs6000_maybe_emit_fp_cmove. Or why not? The IF_THEN_ELSE we
> generate there should work fine?
>
> > +(define_expand "mov<mode>cc"
> > + [(set (match_operand:IEEE128 0 "gpc_reg_operand")
> > + (if_then_else:IEEE128 (match_operand 1 "comparison_operator")
> > + (match_operand:IEEE128 2 "gpc_reg_operand")
> > + (match_operand:IEEE128 3 "gpc_reg_operand")))]
> > + "TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (<MODE>mode)"
> > +{
> > + if (rs6000_emit_cmove (operands[0], operands[1], operands[2],
> > operands[3]))
> > + DONE;
> > + else
> > + FAIL;
> > +})
>
> Why is this a special pattern anyway? Why can you not do
> d = cond ? x : y;
> with cond any comparison, not even including any floating point
> possibly?
Well in theory you can certainly do this, we just need to add the necessary
code to implement it. It quickly becomes an exponential cascading pattern,
where you have one set of modes for the comparison and a different set of modes
for the movement.
I've certainly seen instances where the code has an integer comparison and then
a FP move. We can do this via a SETBC type instruction, direct move, and then
XXSEL. But that is beyond the scope of this patch.
If you remember, the original form of this patch allowed the comparison to be
SF, DF, KF, and possibly TF, along with the move. It becomes complicated when
you have to consider that SF/DF comparisons only fill the upper 64 bits of the
vector register with the comparison, and the IEEE 128-bit types need to be in
Altivec registers.
So I scaled back the patch to just allow 128-bit conditional move. I left in
the existing 64/34-bit mixture because there was at least one benchmark it was
used in the past.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
