On Fri, Sep 15, 2017 at 02:06:22PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 08:40:41PM +0200, Jakub Jelinek wrote:
> > > > I'm greatly oversimplifying here. Type promotion/demotion is fairly
> > > > complex to get right.
> > >
> > > Yeah :-(
> > >
> > > Maybe the best thing is to promote really early, but to keep track of
> > > which
> > > bits matter. And then adjust some passes to take that into account. Not
> > > a
> > > trivial amount of work.
> >
> > Is type promotion actually what we want to do early? I'd think type
> > demotion is what better canonicalizes the IL and removes redundant
> > operations (e.g. those affecting only high bits if we only care about low
> > bits).
>
> On gimple we already have smallest type possible, I think? When expanding
It is worse than you think then. We don't. Just try:
int foo (__int128 x, __int128 y)
{
__int128 z, a, b;
z = x + y;
a = z * 4;
b = a - x;
return b;
}
int bar (long long x, int y)
{
x *= y;
x += 0xffeb0000000000LL;
return x;
}
We keep the user selected types up to expansion, e.g. the x +=
0xffeb0000000000LL;
is completely useless etc. If we demoted, we could
perform all the computation on unsigned int. The only place we have
demotion is the get_unwidened etc. stuff that is done in convert.c, but that
is done only in the FEs and thus only happens within the same statement.
There is nothing that repeats that on GIMPLE.
A disadvantage of demotion (either the one we do in the FEs or the one we
don't do on GIMPLE) is that for signed wider arithmetics if we demote we
need unsigned arithmetics.
Jakub
