Re: Designs for better debug info in GCC

[Alexandre Oliva <aoliva@redhat.com>]

On Dec 19, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

>> Now, if z_5 were present in a debug expression, then it would need
>> adjusting.  No different from the adjusting need for any other
>> instruction in which z_5 was present, though.

> uh, but if you don't adjust in the fixed examples, DEBUG(x, x_4) will
> give an invalid value.

My point was that optimizers already had to know how to adjust things
such that it doesn't break code.

Now, in this optimization, it takes additional liberties with existing
variables because it sees they're only used within the sequence.
IMHO, it would be more appropriate to introduce alternate temporaries,
rather than reusing SSA names for different purposes, in this case.
If this approach was taken, the debug annotations referring to a
no-longer-defined SSA name would be recognized as invalid, and the
variable binding would be removed (i.e., turned into a "value unknown"
annotation).  Or, if we left the definitions in place, even though
they're dead, the same code that cleans up undefined SSA names could
recognize these SSA names as unused except in debug information and
substitute them for their values, maintaining accurate and complete
debug information.

But can we do better without introducing more SSA names and keeping
assignments around that are known to be dead?  Yes, with some
additional effort, see below.

> How do i know i need to change this DEBUG expression.

As reassoc looks for sets of variables it can freely mess with, it
should take note of variables that are used in debug annotations in
addition to the kind of single (?) non-debug uses it's interested in,
such that, when it modifies these variables, the annotations can be
compensated for.

OTOH, if the compiler performs reassoc on user variables today, it
means we do get mangled debug information for such variables already,
and they get incorrect values.  So, even if we didn't address this
problem right away, it wouldn't be much of a regression.

But, of course, not dealing with it breaks the goal of having correct
debug information, so it ought to be dealt with properly.

Do you happen to have a yummy testcase handy that I could use to
trigger this kind of transformation in ways that affect the value of
user variables?

Thanks in advance,

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