https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105007
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
Summary|CDDCE sometimes makes a var |EVRP lattice propagation
|in debug info not available |sometimes makes a var in
| |debug info not available
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Before cddce1:
> <bb 2> :
> # DEBUG BEGIN_STMT
> # DEBUG l_3 => 5
> # DEBUG i => 0
> # DEBUG BEGIN_STMT
> goto <bb 4>; [INV]
>
> <bb 3> :
> # DEBUG BEGIN_STMT
> i_6 = i_1 + 1;
> # DEBUG i => i_6
>
> <bb 4> :
> # i_1 = PHI <0(2), i_6(3)>
> # DEBUG i => i_1
> # DEBUG BEGIN_STMT
> if (i_1 != 8)
> goto <bb 3>; [INV]
> else
> goto <bb 5>; [INV]
>
> <bb 5> :
> # DEBUG BEGIN_STMT
> test (5, 8);
>
> After:
> <bb 2> [local count: 1073741824]:
> # DEBUG BEGIN_STMT
> # DEBUG l_3 => 5
> # DEBUG i => 0
> # DEBUG BEGIN_STMT
> # DEBUG i => NULL
> # DEBUG BEGIN_STMT
> # DEBUG BEGIN_STMT
> test (5, 8); [tail call]
>
>
> Note CCP is able to figure out l_3 => 5 piece. When VRP figures out i => 8
> and changes "i_1 <= 7" into "i_1 != 8", it does not add a debug statement
> for i => 8 after the branch (thinking it does not need one, I don't think it
> needs one but CDDEC should be fixed such that it change i => NULL to 8 I
> think ....)
Passes usually do not try to be too clever in creating debuginfo, in this
case inserting a debug-bind with a loop final value. Instead CDDCE does
it correctly and resets 'i' from the initial value.
<bb 2> :
[t.c:3:4] # DEBUG BEGIN_STMT
[t.c:3:8] # DEBUG l_3 => 5
[t.c:3:17] # DEBUG i => 0
[t.c:4:4] # DEBUG BEGIN_STMT
# DEBUG i => NULL
[t.c:4:13] # DEBUG BEGIN_STMT
[t.c:6:4] # DEBUG BEGIN_STMT
[t.c:6:4] test (5, 8);
[t.c:7:1] return;
I think that's exactly OK. What's the thing to improve is EVRP which does
void foo ()
{
int i;
@@ -37,14 +58,14 @@
# i_1 = PHI <[t.c:3:17] 0(2), [t.c:4:19] i_6(3)>
# DEBUG i => i_1
[t.c:4:13] # DEBUG BEGIN_STMT
- [t.c:4:13] if (i_1 <= 7)
+ [t.c:4:13] if (i_1 != 8)
goto <bb 3>; [INV]
else
goto <bb 5>; [INV]
<bb 5> :
[t.c:6:4] # DEBUG BEGIN_STMT
- [t.c:6:4] test (5, i_1);
+ [t.c:6:4] test (5, 8);
[t.c:7:1] return;
as you say, but when propagating a constant it should make sure to insert
a debug stmt at the definition it removes (it doesn't remove any - but
in principle it adds i_42 = 8; in bb5 and updates SSA form to use the new
name in dominating stmts). This isn't an issue with CCP which doesn't
have contextual lattices, so there's always a definition that is later
replaced with a debug stmt.
The substitute-and-fold machinery could in principle be taught to do this,
but it would need to know whether it faces a "contextual" value (constant
or SSA name) or if there's an actual definition with the propagated value.
Not sure why this should be classified as wrong-debug - the debug info is
conservatively correct. It's just lacking ...
