Re: PR 23551: why should we coalesce inlined variables?

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2007-07-09 at 15:37 -0300, Alexandre Oliva wrote:
> On Jul  9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
> 
> > coalesce foo_3 = bar_2 to bar_2:
> > foo_1 = 
> > bar_2  = 
> > bar_4 = bar_2 - 1
> > foo_5 = bar_2 - 1
> 
> > debug table:
> > [1] = foo
> > [2] = bar foo
> > [4] = bar
> > [5] = foo
> 
> And now this is either wrong or incomplete.  How do you get from the
> debug table above to something that will reflect the fact that foo
> should only hold the bar_2 value at the point foo_3 was assigned to?
> This is what I'm getting at.  You've discarded this information
> without leaving any traces of it.

Thats true, but in today's world, we wouldn't coalesce those variables
so its not an issue at the moment :-). there is a reason we leave 2 user
variables alone you know :-)   we will get a lot of other things better
than we have today by coding things with this kind of mapping.  And for
the sake of optimization, you *will* have to make some sacrifices in
debug info.

we may eventually decide we want to coalescing user variables. Maybe we
can handle this with a NOP use of foo_1 where the old copy was, or some
such thing,  but keeping that sort of thing around can be a nightmare
and tends to inhibit optimization which is not the desired goal. I'd
like to find something better than that, or simply not enable it. It
rarely buys us much in performance, and has been considered an
acceptable tradeoff. 

Right now, I think the first step is to separate the base name from the
debug name. once that ability is there, we'll have much better info than
we have today, and we can look at further subdividing an ssa_names range
somehow if its appropriate.

Along the way we can work out a possible better way to track user
variables that are coalesced so we can enable that.

Is there some kind of issue with inline parameter names, and if so, what
is it?
 

Andrew