This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PR debug/41343] introduce debug expr temps
On Wed, Sep 23, 2009 at 1:37 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 10:17 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Tue, Sep 22, 2009 at 9:32 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> This patch enables VTA to assign debug-only names to expressions
>>> formerly computed at a certain point in the code stream, and then use
>>> these names to replace the removed/modified identifiers, instead of
>>> substituting the identifiers for the assigned expression.
>>>
>>> IOW, if we start from:
>>>
>>> foo_3 = a_1 + b_2;
>>> ...
>>> # DEBUG x => foo_3 + bar_4
>>>
>>> if we remove the DEF of foo_3, we should get:
>>>
>>> # DEBUG D#1 => a_1 + b_2
>>> ...
>>> # DEBUG x => D#1 + bar_4
>>>
>>> D# are names for debug temps, represented as another kind of
>>> declaration, that never appears in expressions other than debug stmts,
>>> and with counters that don't interfere with the regular declaration
>>> counters (messing with the would cause codegen differences).
>>>
>>> This idea came out of Andrew Macleod's debug locus specification. ?The
>>> exponential growth of expressions in debug stmts, reported in PR 41343,
>>> made it obvious that we needed something along these lines sooner rather
>>> than later.
>>>
>>>
>>> I'm not entirely happy with this patch, but it might serve as a stopgap
>>> for the time being. ?Some of the points that could be improved are:
>>>
>>> - use something smaller than a DECL structure for DEBUG_EXPR_DECLs. ?We
>>> don't need all the stuff in a DECL, just a uid, a TYPE, a MODE (could be
>>> inferred from the TYPE), and an RTL expansion
>>
>> Use an SSA name with a single unique base variable?
>>
>>> - avoid emitting multiple redundant copies of the same debug bind stmt
>>> when removing an SSA DEF (*)
>>
>> I don't know if you do it (didn't look into the patch yet), but you can avoid
>> the DEBU_STMTs for single- and zero-use names by keep propagating
>> or doing nothing.
>>
>>> - maybe linking VALUEs of DEBUG_EXPR_DECL and the corresponding
>>> expression by VALUE equivalence, rather than handling DECL_EXPR_DECLs as
>>> another kind of variable in var-tracking
>>>
>>> - use the explicit presence of DEBUG_EXPR_DECLs to decide whether to use
>>> DW_OP_calls for complex sub-expressions, or inline the subexpressions in
>>> location encoding
>>>
>>> - use tuple assign-like forms for debug bind stmts, now possible because
>>> the expression forms are simpler
>>
>> Which wouldn't work anymore if you'd propagate in the single-use case
>> (but for the time being that would save some stmts and decls).
>>
>>> (*)
>>>
>>> ATM we decide to propagate the DEF into debug stmts, we no longer know
>>> even in which block it used to be. ?If it has already been unlinked, we
>>> can't even emit the debug bind stmt right before or right after it.
>>>
>>> I ended up implementing code to emit multiple copies of the debug bind
>>> stmt, right before each USE.
>>>
>>> We could do much better, emitting always a single copy of the debug bind
>>> stmt, say at the block that dominates all USEs, right before the
>>> earliest USE in that block, if there is any, or at the end of the block
>>> otherwise.
>>>
>>> But it would be much simpler to just emit the DEBUG use when unlinking
>>> the DEF, so that it remains in the right place. ?Failing that, we might
>>> have to be concerned about expressions that vary between the DEF point
>>> and the USE point, say references to global variables or memory
>>> locations. ?Code that was in place before simply disregarded that, but
>>> introducing debug temps always at the def point would be a simple and
>>> clean way to fix this, for var-tracking already takes care of noticing
>>> changes and dropping equivalences.
>>
>> Uh. ?Please rework that to emit the debug temps at the place of the
>> DEF.
>
> 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?
> 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
>
> ? ?Not any easier I guess. ?In fact it seems that propagating a non-expression
> or register RHS is always bogus and possibly creates wrong debug information
> if it doesn't consult alias information?
>
> Testcase:
>
> int a;
>
> int foo()
> {
> ?int tmp = a;
> ?int tmp2 = a;
> ?int tmp3;
> ?int res;
> ?a = 0;
> ?tmp3 = tmp2;
> ?res = tmp - tmp2 + 1;
> ?return res;
> }
>
> and after the copyprop after FRE we have
>
> <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 - so whenever we do such thing
(code hoisting, scheduling, sinking) all debug insns that "alias" and
we happen to cross have to be invalidated.
:/
I think there's a load of wrong-debug issues latent right now.
Richard.