This is the mail archive of the
mailing list for the GCC project.
Re: Expansion of narrowing math built-ins into power instructions
Tejas Joshi <firstname.lastname@example.org> writes:
>> It's just a different name, nothing more, nothing less. Because it is
>> a different name it can not be accidentally generated from actual
> 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
(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. :-)
> On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
> <email@example.com> wrote:
>> Segher Boessenkool <firstname.lastname@example.org> writes:
>> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
>> >> Tejas Joshi <email@example.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.