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

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2007-05-10 at 17:55 -0300, Alexandre Oliva 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.
> 

The distinction was originally made based on variables the user declared
in the function. Any inlined variables are present or not present
depending on whether a function was inlined or not. And these are often
copied to another variable. The actual user variables for the function
are always there regardless of -O0 or -O2, so we'd be losing extra info
at -O2.   In addition, user variables within a function seem to not get
copied to each other very often, so the performance impact also appeared
to be less significant. 

Its a thin line, but if we didn't draw it somewhere, we really destroyed
debug info badly.  renaming the inlined variables was deemed to be an
acceptable degradation because there was sometimes significant compile
time impact.

Like I said, I have considered dripping the user variable restriction as
well, but I cna hear the debug complaints already :-)

Andrew