Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool <segher@kernel.crashing.org>]

> > [ Please don't top-post ]

On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote:
> Sorry for not being clear. I am confused about some modes here. I
> meant, just as we expanded fadd (which narrows down from double to
> float) with add_truncdfsf3, how can I expand faddl (which narrows down
> long double to float). Wouldn't I require TFmode -> SFmode as
> add_trunctfsf3 just as Joseph had previously mentioned?

Yes, you need an addsfkf2 as well as adddfkf2 (and tf variants of those,
there are iterators for that).

KF is IEEE QP float.  TF is whatever long double maps to, IEEE QP or
double-double.

> And if yes,
> the operand constraints would still be f,d and d for TF->SF or what?

SF is "f".  KF does not fit in "d".

You won't need constraints anyway.  There already is add<mode>3_odd and
you can just use that, in a new defione_expand you make.  For example,
for DP you need two insns: xsaddqpo followed by xscvqpdp.  The second
of those is the existing insn pattern trunc<mode>df2_hw, so you just get
something like

(define_expand "adddfkf2"
  [(set (match_operand:DF 0 "gpc_reg_operand")
        (unspec:DF [(match_operand:IEEE128 1 "gpc_reg_operand")
		    (match_operand:IEEE128 2 "gpc_reg_operand")]
		   UNSPEC_DUNNO_MENTION_DF_SOMEHOW))]
  "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (<MODE>mode)"
{
  rtx tmp = gen_reg_rtx (<MODE>mode);
  emit_insn (gen_add<mode>3_odd (tmp, operands[1])))), operands[2]);
  emit_insn (trunc<mode>df2_hw (operands[0], tmp));
  DONE;
})

(not tested at all, be careful :-) )

> Also, just as we generated fadds/xsaddsp instructions for fadd, would
> I be generating the same ones for faddl and fadd/xsadddp for daddl
> (long double to double) or something different? all for ISA 2.07. (for
> ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
> add<mode>_odd followed by conversion to narrower?)

For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
that is.  I don't know if we'll want fadd support in the emulation
libraries ever; don't worry about it for now, anyway.

"long double is double" you should probably handle in generic code.
"long double is double-double", well, fadd cannot really be done better
than an add followed by a conversion in that case?  Which boils down
to truncating the inputs to double, and then doing whatever you would
do for IEEE DP float.


Segher