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

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2007-05-15 at 02:41 -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.  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?

Memory consumption was never a concern of mine, sorry if that wasn't
clear. I presumed the discussion of lots of extra copies laying around
because of a lack of coalescing made that clear.  Runtime performance is
the original reason for this code.  Have we got a spec run or anything
like that which shows no degradation on non-trival tests?

This code pre-dates the ssa-inliner, so it is possible its not as
relevant as it once was. Do you have a specific example in mind when it
makes a big difference for you that I can have a look at?  (a .i would
be grand)

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

Why bother changing them to anonymous names and then back? I certainly
find seeing them in ssa form makes reading intermediate code easier to
map back to source. If you can maintain a mapping of anonymous names to
user names, you can just as easily include the original user name
variables in the mapping.


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

I think we are better off simply trying to map individual ssa-names to a
user name where appropriate. SSA-names already have the property of
single assignment. You would lose precision when you have multiple user
vars on the RHS of a PHI, but a little detective work may make choosing
one of the candidates easier/more obvious for the LHS ssa-name. (ie, 8
references to one name, 1 to another implies the 8 is probably the right
choice, things like that)

No one has gotten around to trying this, so I would expect this to be a
better initial approach than anything which changes the representation.
I'd be suprised if this didn't do most of what we need.

Andrew