This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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)


On Thu, 15 Aug 2019 at 02:30, Segher Boessenkool
<> wrote:
> On Wed, Aug 14, 2019 at 08:23:27PM +0000, Joseph Myers wrote:
> > On Wed, 14 Aug 2019, Segher Boessenkool wrote:
> >
> > > Does something like
> > >   float d; double a, b, x;
> > >   ...
> > >   d = fadd (a + x, b - x);
> > > work as wanted, with such a representation?  It would simplify (does it?) to
> > >   d = fadd (a, b);
> > > but is that allowed?
> >
> > It's not allowed, but neither is simplifying (a + x) + (b - x) into (a +
> > b), when contraction isn't allowed.
> Ah of course.  And we already should not do such simplification on RTL,
> when contraction is disallowed.
> So yeah it should work fine I think.  A new RTL code would be best (it
> would be silly to have to make an unspec for it in every port separately),
> but an unspec is of course easiest for now.
> Segher

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]