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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  9, 2007, Michael Matz <matz@suse.de> wrote:

> That infrastructure obviously also need to take 
> care to update that side information on transformations affecting it.  
> E.g. when propagating an SSA name holding a backing variable into uses 
> without such, you can merge those associations.

But see, if you just merge them, without any information as to the
point in which the merged variable actually starts holding that value,
you corrupt debug info.  This is the point I still don't see how to
accomplish based on your suggestion.  Are you suggesting that we just
live with this incorrect debug info?  If not, how do you intend to
mark the point of the program in which foo_2 is assigned such that we
can emit debug info for it after it's combined with bar_1?

> If you propagate it into a complicated expression which isn't
> invertible, only then have you broken debug information.

Or if we delete a dead assignment out of values we can't derive from
other locations (e.g., the value returned by a function call).  And
I'm sure there are a number of other cases.  But propagation of foo =
bar; isn't one of these.  We can handle this properly.  My question is
how.  I'm sorry if I'm being dense, but I don't see how your proposal
would enable me to compile the following program with optimization and
debug info, set a breakpoint at (before) the assignment "foo = bar;"
and get "print foo" to print 1 rather than 0.

int i;
int f() {
  asm ("nop");
  return 0;
}
int main() {
  int foo = 1;
  int bar = f ();
  asm("nop");
  foo = bar;
  asm("nop");
  bar++;
  foo--;
  asm("nop");
  i = bar;
  return foo;
}

> But we already know that we simply can not express _all_
> transformations the compiler does to code in debug info (not
> sensibly at least) without actively inhibiting some transformations.

Yes.  I'm not concerned about these cases.  If the information is not
available, then it's not available, too bad, we omit the
optimized-away range from the location list.  But if it is readily
available, I want us to have emit it, and this means preserving the
means to emit it across optimization.

> But also that needs the basic infrastructure of attaching debug
> information to SSA names.

Yup.  No doubt about that.

I'm still no sure, however, whether the better approach is to attach
user variables to SSA names at the point the SSA names are defined, or
the other way round, at the points the names become associated with
the user variables.

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