This is the mail archive of the
mailing list for the GCC project.
Re: Expansion of narrowing math built-ins into power instructions
> 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?
On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
> 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.