This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Expansion of narrowing math built-ins into power instructions
> but an unspec is of course easiest for now.
So, at this point, should I proceed with UNSPEC considering the
complications that might arise as Richard points out?
On Sat, 17 Aug 2019 at 13:51, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> 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