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

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2007-07-09 at 17:46 -0300, Alexandre Oliva wrote:
> 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?
> 

yes. The nature of optimization is that after the last use of a
variable, it goes dead and may not be available any more. Since the
store foo = 1 has no uses, the stmt is dead, and is eliminated. That
means it is simply not available when debugging optimized code. In order
to track things that have been deleted, its a much larger project which
I think should not be pursued until we have gotten other things fixed up
by associating debug symbols with ssa names. Go for the low hanging
fruit first.  That should get us many things we SHOULD be getting now,
and allow the removal of those restrictions in copyrename, as well as
remove any debug issues copyrename introduces.


> 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

<...>

> }
> 
> > 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 it is no longer readily available after optimization. when out of
ssa sees that program, its sees:
 bar_2 = f ();
  __asm__ __volatile__("nop"::);
  __asm__ __volatile__("nop"::);
  bar_5 = bar_2 + 1;
  foo_6 = bar_2 + -1;
  __asm__ __volatile__("nop"::);
  i = bar_5;
  return foo_6;


there is no longer any assignment of 1 to anything in this program, so
it is not readily available. You are trying to track deleted things.
Thats a bigger project.


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

well, if you attach it to an SSA name, you are automatically attaching
it to the def point, thats the nature of ssa being single definition.
in order to be associated to a user variable, it still has to have an
assignment and be attached at a def point, so I'm not sure I understand
the distinction.  Given the transient nature of stmts, if you tried to
make the debug name point to a stmt you'd pull your hair out trying to
keep it straight :-)  


Andrew