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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 7/8/07, Daniel Berlin <dberlin@dberlin.org> wrote:
> On 7/8/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> > On Jul  7, 2007, Jan Hubicka <hubicka@ucw.cz> wrote:
> >
> > >> On Jun 28, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
> > >>
>
> >
> > That said, maybe with the work I have in mind we'll be able to enable
> > coalescing for all user variables (not only those coming from inlined
> > functions), and retain the annotations needed to map the assignments
> > back to user variables somehow.  However, I'm not convinced yet that
> > it can be done in a way that consumes less memory, basically because
> > we'd have to keep track of which variables map to which assignments to
> > SSA variables, and this would amount to further SSA analysis and
> > assignments, or annotations that would have to be dealt with in a very
> > similar way.  That said, ideas are welcome.
>
> This looks like a standard propagation problem you could use
> tree-ssa-propagate to solve, generate the mapping, output debugging
> info, and throw away the mapping.

The problem is that this is a N:M mapping and that we lose parts of
the N during optimization and especially inlining.  The "goal" is
to know every user variable name that a current register refers to.
So we need to keep track of any variable that is propagated into a
register at any time, even if we later manage to get rid of the variable
because it is unused.

Richard.