This is the mail archive of the
mailing list for the GCC project.
Re: PR 23551: why should we coalesce inlined variables?
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Daniel Berlin" <dberlin at dberlin dot org>
- Cc: "Alexandre Oliva" <aoliva at redhat dot com>, "Jan Hubicka" <hubicka at ucw dot cz>, "Andrew MacLeod" <amacleod at redhat dot com>, "Seongbae Park (?????????, ?????????)" <seongbae dot park at gmail dot com>, "Andrew Pinski" <pinskia at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 8 Jul 2007 23:02:13 +0200
- Subject: Re: PR 23551: why should we coalesce inlined variables?
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20070707231032.GD3789@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org> <email@example.com>
On 7/8/07, Daniel Berlin <firstname.lastname@example.org> wrote:
On 7/8/07, Alexandre Oliva <email@example.com> wrote:
> On Jul 7, 2007, Jan Hubicka <firstname.lastname@example.org> wrote:
> >> On Jun 28, 2007, Andrew MacLeod <email@example.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.