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

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

On 5/10/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> On May 10, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:
>
> > On Thu, 2007-05-10 at 04:39 -0300, Alexandre Oliva wrote:
> >> We're discarding useful debug info by SSA-coalescing inlined
> >> variables.  The reason we refrain from coalescing non-inlined
> >> variables is for better debug info.  No other pass pays attention to
> >> DECL_FROM_INLINE, and it doesn't look like we generate significantly
> >> worse code if we refrain from coalescing these variables.
>
> > Not without some real performance measurement.  We originally added this
> > specifically to remove a number of excess copies that heavy inlining
> > produces.
>
> But how does this argument not apply to coalescing of variables that
> are NOT inlined?  If we are intentionally generating sub-optimal code
> for the sake of better debug info in one case, but not in another, and
> I don't see that this distinction is defensible.
>
> > It might also be possible to 'save' the original name in a table, and if
> > a useful coalesce was not performed at out of ssa time, rename the
> > variable back, or choose the most 'useriest' name amongst a coalesce
> > group... That might also help debug info a bit.
>
> Yup, I've been pondering about this and other approaches to avoid
> discarding useful information even while optimizing.  Any pointers and
> suggestions are welcome.

Well, on e thing that we certainly lack is the ability to describe the
one-to-many relationship between gimple registers and user variables
it represents (especially after inlining, as you noted).  So a on-the-side
representation for that would be certainly useful.  This somewhat
resembles what the var-tracking pass does at the rtl level (though in
the complete opposite direction).

Richard.