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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  9, 2007, Andrew MacLeod <amacleod@redhat.com> wrote:

> The nature of optimization is that after the last use of a
> variable, it goes dead and may not be available any more. Since the
> store foo = 1 has no uses, the stmt is dead, and is eliminated.

But debug info can still express that the value is available, since
it's a known constant.  If it was a copy of any other variable still
live, we could still refer to it as well.  That some optimization took
place is not an excuse to not try to emit correct debug information
that could easily be emitted.

Of course, if it was a value that could not possibly be represented in
debug info, then we'd have to emit information indicating that the
value was optimized away.  But this is not the case at hand.

> In order to track things that have been deleted, its a much larger
> project which I think should not be pursued until we have gotten
> other things fixed up by associating debug symbols with ssa names.

My point is that one way to make the association would naturally lead
to this desirable result, *and* wouldn't get us to generate incorrect
debug information without even being able to tell, as in this other
way you've suggested, which wouldn't extend to the desired end result.

That's why I'm planning ahead rather than jumping for low-hanging
fruit, as you suggested yourself before.


So, what's the objection to SSAify something like this:

  foo = f ();
  bar = foo;

into:

  /* foo = */ foo_1 = f ();
  /* bar = foo_1; */

I.e., a separate (or separatable on demand) assignment that doesn't
generate code, doesn't keep the RHS from being optimized away, but
that can be transformed in other ways as the RHS is optimized,
providing the point at which the user variable is assigned the value
computed in that SSA, for debug info purposes?

What I envision is one of two possibilities:

1. When optimizing away a GIMPLE_MODIFY_STMT that modifies a user
variable, mark it or replace it in such a way that it becomes a mere
annotation.

2. Generating the annotations as separate statements upfront.

The latter uses more memory, but makes for a simpler and safer
implementation.

> there is no longer any assignment of 1 to anything in this program, so
> it is not readily available. You are trying to track deleted things.
> Thats a bigger project.

Yes.  I know.  The problem I have to solve is *precisely* the need for
tracking deleted things.  Sure, I can (and will) address other issues
in the process, but unless I accomplish that goal, I won't have solved
the problem I was assigned to solve.

> well, if you attach it to an SSA name, you are automatically attaching
> it to the def point, thats the nature of ssa being single definition.
> in order to be associated to a user variable, it still has to have an
> assignment and be attached at a def point

Which is precisely what makes this attachment insufficient to solve
the problem correctly.

> if you tried to make the debug name point to a stmt you'd pull your
> hair out trying to keep it straight :-)

I'm thinking of either emitting annotation stmts (that will track
themselves) or turning to-be-deleted assignments into such annotation
stmts.

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