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

[Tejas Joshi <tejasjoshi9673 at gmail dot com>]

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?

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