PR 23551: why should we coalesce inlined variables?

[Andrew MacLeod]

On Tue, 2007-07-10 at 14:21 -0300, Alexandre Oliva wrote:
> On Jul  9, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

> How do I generate debug info for bar such that the range in which it's
> associated with foo_1 is 1..2 rather than 0..2?
> 

Its been optimized away, and I consider that a hazard of debugging
optimized code. 

> 
> I've already suggested adding annotations that remain after
> assignments are optimized away, such that we initially have:
> 
> 0: /* foo = */ foo_1 = f ();
> ...
> 1: /* bar = */ bar_1 = foo_1;
> ...
> 2: /* bar = */ bar_2 = f ();
> 
> but then, after optimization, we still have:
> 
> 0: /* foo = */ foo_1 = f ();
> ...
> 1: /* bar = foo_1; */
> ...
> 2: /* bar = */ bar_2 = f ();
> 
> See, now I can emit correct debug info for bar.
> 
> Is there any reason not to do it this way?
> 

  And where are the annotations going to be stored? They have to be
associated with actual stmts in order to retain locale. Since stmts are
often deleted, these will have to be actual stmts, not just annotations.

  Then your use of foo_1 will have to be considered a real use by the
optimizers, or if foo_1 is later turned into foo_7, you will be
referring to a non-existant variable. This will have more ripple effects
than you initially think.

  Once its considered a real use, many existing optimizations will have
to be taught whether this is to be considered a NOP stmt, so this use
doesn't keep things alive, yet it cant be ignored since you don't want
it hoisted to the top of the block either.

  If the def of foo_1 is deleted, then you also need to keep a pretend
DEF around in order to keep your use stmt in place and referrig to
something that exists in the IL. If every other stmt in a BB is deleted,
does the existence of this stmt prevent the block from being removed, or
is this a case we can delete the debug stmt? if its a pretend def, then
any debugging use stmts in other block  will have to be removed too. If
the block can't be removed, thats a serious optimization issue.

 Pretend stmts are much like 'to be deleted' stmts. We've already
experienced keeping stmts around and marking them to be deleted in the
earlier years of tree-ssa. That was the initial model. We've abandoned
it because it was too much work, and maintaining it was a nightmare. I
doubt anyone want to revisit such a thing again.
 
 Thats just off the top of my head. This means the compiler has to keep
around a whole other set of defs and uses that aren't related to
optimization, but which the optimizers and ssa machinery cannot outright
ignore either.  

  So what you are proposing affects a lot of things. Not that it
couldn't be done, but it will be a fair amount of work and I think we
have much lower hanging fruit and pressing issues right now.  It sounds
vaguely like the ASSERT_EXPR model might work along the lines you are
thinking (they don't generate code, just provide hints/information), but
I think those stmts only exists over a short period of compilation, and
it was a lot of work to get them right. In addition, they were also
allowed to move and disappear which wouldnt be so good for this
debugging info.

It also ignores the bigger picture in more complicated situations. When
a bunch of stmts which follow 'bar = foo_1' are moved further down in
the program, or up above this stmt, the debugger isn't going to be
giving sensible results for many things anyway.  So I'm not sure it
really matters if you can print a value which has been optimized away
and has no bearing on anything. Its optimized code that is being
debugged, you have to expect some issues.  As a user, I typically only
truly care about the value of a variable at it USE location. It is used
in this expression, I want to know what its value is. That would
normally be available if we can get a few more simple things right.

Bottom line: Lets start with the easy things and see where it gets us.
Its not much work, and it will not affect compilation speed or memory
usage in any measurable way. It'll be better than what we have today,
and that in turn will make people happier. 

Andrew