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

[Richard Sandiford <richard dot sandiford at arm dot com>]

Tejas Joshi <tejasjoshi9673@gmail.com> writes:
> Hi,
>
>> It's just a different name, nothing more, nothing less.  Because it is
>> a different name it can not be accidentally generated from actual
>> truncations.
>
> I have introduced float_narrow but I could not find appropriate places
> to generate it for a call to fadd instead it to generate a CALL. I
> used GDB to set breakpoints which hit fold_rtx and cse_insn but I got
> confused with the rtx codes and passes which generate respective RTL.
> It should not be similar to FLOAT_TRUNCATE if we want to avoid it
> generating for actual truncations?

Please don't do it this way.  The whole point of the work is that this
is a single operation that cannot be modelled as a post-processing of
a normal double addition result.  It's a single operation at the source
level, a single IFN, a single optab, and a single instruction.  Splitting
it apart into two operations for rtl only, and making it look in rtl terms
like a post-processing of a normal addition result, seems like it's going
to come back to bite us.

In lisp terms we're saying that the operand to the float_narrow is
implicitly quoted:

  (float_narrow:m '(plus:n a b))

so that when float_narrow is evaluated, the argument is the unevaluated
rtl expression "(plus a b)" rather than the evaluated result a + b.
float_narrow then does its own evaluation of a and b and performs a
fused addition and narrowing on the result.

No other rtx rvalue works like this.  rtx nappings like simplification
or evaluation are normally depth-first, so that the mapping is applied
to the operands first, and then the root is mapped/simplified/evaluated
with the results.  Adding implicit lisp quoting would require special
cases in these routines for float_narrow.

The only current analogue I can think of for this is the handling
of zero_extend on const_ints.  Because const_ints are modeless, we have
to avoid cases in which the recursion produces things like:

  (zero_extend:m (const_int -1))

because it's no longer clear what mode the zero_extend is extending from.
But I think that's seen as a wart of having modeless const_ints.  I don't
think it's something we should actively embrace by adding float_narrow.

Using float_narrow would also be inconsistent with the way we handle
saturating arithmetic.  There we use US_PLUS and SS_PLUS rtx codes for
unsigned and signed saturating plus respectively, rather than:

  (unsigned_sat '(plus a b))
  (signed_sat '(plus a b))

Using dedicated codes might seem clunky.  But it's simple, safe, and fits
the existing model without special cases. :-)

Thanks,
Richard

>
> Thanks,
> Tejas
>
>
> On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
> <richard.sandiford@arm.com> wrote:
>>
>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
>> >> Tejas Joshi <tejasjoshi9673@gmail.com> writes:
>> >> > Hello.
>> >> > I just wanted to make sure that I am looking at the correct code here.
>> >> > Except for rtl.def where I should be introducing something like
>> >> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
>> >
>> > I like that "float_narrow" name :-)
>> >
>> >> > set on functions around expr.c, cfgexpand.c where I grep for
>> >> > float_truncate/FLOAT_TRUNCATE did not hit.
>> >> > Also, in what manner should float_contract/narrow be different from
>> >> > float_truncate as both are trying to do similar things? (truncation
>> >> > from DF to SF)
>> >>
>> >> I think the code should instead be a fused addition and truncation,
>> >> a bit like FMA is a fused addition and multiplication.  Describing it as
>> >> a DFmode addition followed by some conversion to SF would still involve
>> >> double rounding.
>> >
>> > How so?  It would *mean* there is only single rounding, even!  That's
>> > the whole point of it.
>>
>> But a PLUS should behave as a PLUS in any context.  Making its
>> behaviour dependent on the containing rtxes (if any) would be a
>> can of worms.
>>
>> Richard