http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51570
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-12-16
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-16
09:08:09 UTC ---
This got "broken" by my ENTRY_VALUE patches, and apparently even Alex'
"Keep static VTA locs in cselib tables only" patch doesn't cure it.
We have:
(debug_insn 6 3 7 2 (var_location:HI D#2 (mem:HI (reg/v/f:DI 5 di [orig:62 p ]
[62]) [0 *p_1(D)+0 S2 A16])) pr45003-3.c:8 -1
(nil))
(debug_insn 7 6 8 2 (var_location:HI D#1 (debug_expr:HI D#2)) pr45003-3.c:8 -1
(nil))
(debug_insn 8 7 9 2 (var_location:SI a (sign_extend:SI (debug_expr:HI D#1)))
pr45003-3.c:8 -1
(nil))
(insn:TI 9 8 10 2 (set (reg:SI 5 di [orig:60 D.1725 ] [60])
(zero_extend:SI (mem:HI (reg/v/f:DI 5 di [orig:62 p ] [62]) [2
*p_1(D)+0 S2 A16]))) pr45003-3.c:9 117 {*zero_extendhisi2_movzwl}
(nil))
The PR45003 improvement noted during var-tracking the reverse operation of
(zero_extend:SI (mem:HI (di))))
i.e. that the value of D#2 (and D#1) can be computed as (subreg:HI (reg:SI di))
after insn 9. Thus before ENTRY_VALUE changes, we'd see that the p pointer
value isn't live after that insn anywhere and the only way to compute it would
be to go back, see that (mem:HI (value of p on entry)) is live in (subreg:HI
(reg:SI di)) and just emit the sign extension of it.
Now, with ENTRY_VALUE, even when we keep it as lowest priority alternative,
we have a place where the value of p on entry is live - (entry_value:DI rdi)
and thus we just use it and don't look further.
This testcase will work just fine with GDB 7.4 which finally supports
DW_OP_GNU_entry_value (just verified that), but that wasn't the actual goal of
the testcase, it is trivial to modify the testcase so that it will fail even
with GDB 7.4:
--- gcc/testsuite/gcc.dg/guality/pr45003-3.c.jj 2010-11-19
20:56:33.000000000 +0100
+++ gcc/testsuite/gcc.dg/guality/pr45003-3.c 2011-12-16 10:01:36.170231171
+0100
@@ -24,8 +24,12 @@ int
main ()
{
unsigned short us = 0x8078;
- foo (&us);
+ unsigned short *pus = &us;
+ asm volatile ("" : "+r" (pus));
+ foo (pus);
short s = -32648;
- bar (&s);
+ short *ps = &s;
+ asm volatile ("" : "+r" (ps));
+ bar (ps);
return 0;
}
Then on the call site we don't know what is the value passed to the functions,
and as those values aren't needed afterwards, they aren't saved anywhere.
So, yes, entry_value should have the lowest priority of everything.
To fix this we'd need to cache during vt_emit_notes not just a single
expression, but at most two, one that doesn't use any entry_value expressions
and one that does. To build the complete expressions for the notes we'd first
try if we can build up an expression entirely without any entry_values, and
only if it fails, supply one with entry_values. If we did no caching, we could
of course just try to expand twice and ignore entry_value in the first round,
but we really can't avoid the caching, the memory consumption and compile time
complexity was huge on some testcases.
