PR 23551: why should we coalesce inlined variables?

[Andrew MacLeod]

On Mon, 2007-07-09 at 16:08 +0200, Richard Guenther wrote:
> On 7/9/07, Andrew MacLeod <amacleod@redhat.com> wrote:
> > On Sun, 2007-07-08 at 22:24 -0300, Alexandre Oliva wrote:
> >
> > The problem we have is that we don't separate out the debug info name
> > from the ssa_variable name.  That is the first step.  I think we should
> > follow something like the following:
> >
> > 1 - Add a link for each ssa name to the debug symbol. Either in a side
> > table, or in the ssa-name itself. Doesn't matter. It should only be
> > set/examined via access routines/macros so the underlying implementation
> > is initially unimportant.
> 
> We probably will need to end up with a list of debug symbols per ssa-name.
> One deficiency of the current machinery is that we can only track one, so
> for example at inlining we either forget the name of the parameter in the
> call expr or the name of the argument in the function decl.

yeah, once we have the initial bits in place, we can see whats left and
deal with them. Something like function arguments/parameters are almost
'hard' bound. ie, they will *always* be linked, so you can simply note
that whenever we issue debug info for 'arg' you also issue the same for
'value'.. then you dont need to track it through all the ssa_name
variations either.

 Softer links such as through coalescing will likely need a chain, but
we can fool with that and all the intricacies involved when we get
there.

Andrew