This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Designs for better debug info in GCC

On Dec 19, 2007, "Daniel Berlin" <> 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
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]