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

[Jan Hubicka <hubicka at ucw dot cz>]

> On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
> 
> > It shoulnd't be too hard to get this working to the point that it is as good
> > as with your patch disabling coalescing (which you say doesn't help anyway
> > as optimization passes do this coalescing by propagation anyway).
> 
> That's the thing, I don't see how it's going to be accomplished if we
> just throw that assignment away.  And if we don't, whether we coalesce
> or not is irrelevant, we have to keep an annotation at that point to
> indicate the state of some user variable changed at that point.  And

If we end up having arbitrary copy instructions to represent this, we
will lose quality of code for heavy C++ inlining.  It still seems to me
that we should just record list of variables belonging to given SSA name
(as suggested by Andrew) or variable (as I suggested earlier, that might
be easier to get down to RTL land where SSA names are gone, but we might
also tie SSA names into RTL REG attributes instead to get better info).

Then we will have information like "this register contains value of user
variable A,B,C" and we output the info to debugger (as opposed to
current 1-1 mapping).

It is not perfect, since the register change meaning depending on
position in program.  However without disabling substantial amout of
optimizations (think of C++ program where each final instruction has its
own unique scope and inlined functions, like tramp3d) that introduce
some sort of barriers in between use as old meaning and use in new
meaning, the position in program is not well defined anyway.  Debugger
also knows the scope block of current instruction so it will give access
only to those variables from list existing in the scope at the given
point in program...

Honza
> if we only add that annotation when generating debug information, odds
> are that we'll change generated code depending on -g, which is a
> non-starter.  So no matter how I look at it, there is going to be some
> increase in memory use because we'll have to keep more info.
> 
> I have no doubt that there are different and quite likely more
> efficient ways to do it than my first-cut approach that only removes
> an artificial, arbitrary and incorrect distinction between certain
> kinds of user variables.  As you suggested yourself, we'd be better
> off making the change in the other direction, as in the new patch I've
> proposed.
> 
> Then the work I'm supposed to be doing (rather than explaining why
> better debug info is necessary ;-) will be able to make up for the
> removed information.  But it will amount to some increase in memory
> use, there's no escaping to it.
> 
> -- 
> 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}