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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:

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

It is, because as I found out after my first patch, coalescing is not
the only issue.  The variable dies because bar is propagated over, and
then the assignment becomes dead and is deleted.  But we fail to emit
debug info even though the value is available.  Here's a testcase that
might look very familiar to you:  :-)

int i, j;
int main(int argc, char *argv[]) {
  int foo;
  int bar = argc;
  asm("");
  foo = bar;
  asm("");
  bar++;
  foo--;
  asm("");
  i = bar;
  j = foo;
}

> there is a reason we leave 2 user variables alone you know :-)

Unfortunately, as I found out, we don't.  If only it were that
simple...

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

Exactly.  That's why I'm now thinking of some other means to keep
annotations about the assignments around, but in a way that doesn't
trigger generation of code, and that doesn't keep assignments from
being optimized away.  Then, if we get to a point in which we need
some value that isn't available anywhere, we can emit debug info
saying the value of the variable was optimized away at that point,
rather than retaining an incorrect value.

However, if we can still express the value in terms of other available
expressions, we should use them.  That's a longer-term goal I have in
mind, hopefully not something I'll need to fix right away.  But it's
something I'm trying to take into account in my planning.

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

Depending on the way this separation is introduced, it may be a
mechanism that can be used to retain information about deleted
assignments, or that will require us to invent yet another mechanism
to retain that information.  Which is why I don't intend to plan this
as a separate step: I believe they can both be done with a single
construct.

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

I don't quite see the point of not coalescing user variables ATM, and
it doubles the memory use for a known test case, so I think we should
just stop pretending that not coalescing them does any good for debug
info.

> Is there some kind of issue with inline parameter names, and if so, what
> is it?
 
Not only parameter names, but also inlined variables.  They just go
away.  One of the issues with inlined parameters is that the inliner
currently refrains from emitting them in the first place, because
they'd be coalesced right away.  But changing that made no difference
whatsoever, it's a much deeper problem.  I was going to submit a patch
to fix that, but once we've determined that small steps toward
preserving more debug info aren't going to fly because they won't show
immediate results, I just saved that for another time.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}