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

[Alexandre Oliva <aoliva at redhat dot com>]

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.  So...
>> 
>> May I check this in if it passes bootstrap and regression testing on
>> x86_64-linux-gnu?

> Not without some real performance measurement.

So, now that we have them (at least as far as memory consumption is
concerned; code doesn't change significantly either AFAICT), can it go
in?

> 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.

I'm here wondering if we could completely do away with non-addressable
user variables very early in the compilation, replacing all of them 
with anonymized variables that can be coalesced and optimized at will,
but replacing assignments to user variables with annotations that map
the user variable to the anonymized variable that holds its value.

Such annotations would be regular variables for many purposes, but
they'd never be refereced in RHSes, nor would assignments to them be
removed.

I'm thinking whether it would be possible to do this without killing
other optimizations, and also how to handle PHI nodes for such
debug-only variables.  I don't see that we can count on always having
some other variable that would provide us with the PHI node we'd need
to provide a valid mapping for the variable.

Does this even begin to make any sense?  Has anyone seen any such
approach used or at least presented anywhere?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}