Re: [PR debug/41343] introduce debug expr temps

[Alexandre Oliva <aoliva at redhat dot com>]

On Sep 23, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

>> Hmhm. ÂThinking about this I'm not sure how new debug temps at the definition
>> site would work. ÂConsider

>> a = 1;
>> # DEBUG D#1 => a
>> ..
>> a = 0;
>> # DEBUG i => D#1

>> how would the debug info look like so that gdb picks up the correct
>> value of a if we do 'print i' at the location of the debug stmt for it?

Remember that a lot of stuff happens between having notes and emtting
the actual debug info, and don't forget that the debug bind statements
bind values, rather than locations.

In var-tracking, when we reach the D#1 => a debug insn (it won't be a
any longer, but a REG or MEM, but that's a detail we can disregard),
we'll note that D#1 binds to a VALUE rtx that is, at that point,
equivalent to the REG or MEM where the (const_int 1) was stored, and to
the constant integer itself.

Later on, when var-tracking notices that that REG or MEM is modified, it
discards the equivalence between the VALUE and the REG or MEM.

Then, when i is bound to the value of D#1, we emit a location for i
corresponding to the equivalences of that VALUE at the bind point of i.
The REG or MEM will have already been discarded.

Likewise, if D#1 was a regular variable, rather than a debug temp, we'd
emit a location note for D#1 at its bind point, and when we reached âa =
0â, we'd emit another location note reflecting the change to the value.

>> How would things work here if the debug temp would be placed before
>> the use like
>> 
>> Âa = 1;
>> ...
>> Âa = 0;
>> # DEBUG D#1 => a
>> # DEBUG i => D#1

This transformation would be an error.  It should not happen.  I don't
have any evidence that it does.

The current propagation of debug values may indeed be introducing this
kind of distortion when it comes to non-gimple-regs, mems, etc.  An
upcoming version of this patch should fix it, emitting debug temps
*always* at the location of the removed assignment.

>> <bb 2>:
>> Â# DEBUG tmp => a
>> Â# DEBUG tmp2 => a
>> Âa = 0;
>> Â# DEBUG tmp3 => a
>> Âres_5 = 1;
>> Â# DEBUG res => res_5
>> Âreturn res_5;
>> 
>> so suddenly printing tmp3 will print 0.

> In fact nothing is preventing the a = 0; store to be moved before
> the two other debug stmts either

What's preventing it is the same code that prevents us from breaking
executable code.  Say, if we had:

  <bb 2>
    foo = a;
    a = 0

we wouldn't be allowed to move a = 0 before foo = a.  Optimizers
shouldn't ignore uses along the way, and although they might have to
disregard debug stmts when making decision, they ought to adjust them
just like they would should they make transformations that would affect
executable code.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer