[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562 --- Comment #4 from Richard Biener --- (In reply to Richard Biener from comment #3) > Just to put it somewhere I ran dwlocstat on cc1plus before/after the > offending change and it looks almost the same. We go from > > cov%samples cumul > 0..10 1280217/38% 1280217/38% > 11..20 55668/1%1335885/40% > 21..30 68004/2%1403889/42% > 31..40 70774/2%1474663/44% > 41..50 75554/2%1550217/46% > 51..60 91816/2%1642033/49% > 61..70 101139/3% 1743172/52% > 71..80 135281/4% 1878453/56% > 81..90 198470/5% 2076923/62% > 91..100 1233822/37% 3310745/100% > > to > > cov%samples cumul > 0..10 1280197/38% 1280197/38% > 11..20 55669/1%1335866/40% > 21..30 68014/2%1403880/42% > 31..40 70773/2%1474653/44% > 41..50 75542/2%1550195/46% > 51..60 91800/2%1641995/49% > 61..70 101133/3% 1743128/52% > 71..80 135259/4% 1878387/56% > 81..90 198496/5% 2076883/62% > 91..100 1233844/37% 3310727/100% And with up-to-date elfutils to avoid some DWARF5 issues cov%samples cumul 0..10 1280347/38% 1280347/38% 11..20 55720/1%1336067/40% 21..30 68040/2%1404107/42% 31..40 70805/2%1474912/44% 41..50 75585/2%1550497/46% 51..60 91850/2%1642347/49% 61..70 101224/3% 1743571/52% 71..80 135406/4% 1878977/56% 81..90 198509/5% 2077486/62% 91..100 1233880/37% 3311366/100% to cov%samples cumul 0..10 1280327/38% 1280327/38% 11..20 55721/1%1336048/40% 21..30 68050/2%1404098/42% 31..40 70804/2%1474902/44% 41..50 75573/2%1550475/46% 51..60 91834/2%1642309/49% 61..70 101218/3% 1743527/52% 71..80 135384/4% 1878911/56% 81..90 198535/5% 2077446/62% 91..100 1233902/37% 3311348/100%
[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562 --- Comment #3 from Richard Biener --- Just to put it somewhere I ran dwlocstat on cc1plus before/after the offending change and it looks almost the same. We go from cov%samples cumul 0..10 1280217/38% 1280217/38% 11..20 55668/1%1335885/40% 21..30 68004/2%1403889/42% 31..40 70774/2%1474663/44% 41..50 75554/2%1550217/46% 51..60 91816/2%1642033/49% 61..70 101139/3% 1743172/52% 71..80 135281/4% 1878453/56% 81..90 198470/5% 2076923/62% 91..100 1233822/37% 3310745/100% to cov%samples cumul 0..10 1280197/38% 1280197/38% 11..20 55669/1%1335866/40% 21..30 68014/2%1403880/42% 31..40 70773/2%1474653/44% 41..50 75542/2%1550195/46% 51..60 91800/2%1641995/49% 61..70 101133/3% 1743128/52% 71..80 135259/4% 1878387/56% 81..90 198496/5% 2076883/62% 91..100 1233844/37% 3310727/100%
[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #2 from Richard Biener ---
So the first difference is
@@ -4076,36 +4076,47 @@
fbt (0x7700b468: (reg/f:SI 16 argp)) == (address:SI -4)
fbt (0x771f6a68: (plus:SI (minus:SI (value/u/j:SI 13:4329
@0x4a213b0/0x498b
600)
(value/u:SI 20:8682 @0x4a21458/0x498b750))
-(const_int -12 [0xfff4]))) == (address:SI -1)
-bac false
+(const_int -12 [0xfff4]))) == (nil)
+bac true
and the obvioys thinbg to notice is that while we'll recurse through the
PLUS the MINUS has two VALUE operands which we'd give up upon (rightfully so).
Note this is disambiguating
(mem/c:SI (value/u:SI 1:1 @0x4a21290/0x498b3c0) [2 a+0 S4 A32])
against
(mem:SI (value/u/j:SI 24:21724 @0x4a214b8/0x498b810) [2 S4 A32])
with one address being (reg/f:SI 16 argp) and one
(plus:SI (minus:SI (value/u/j:SI 13:4329 @0x4a213b0/0x498b600)
(value/u:SI 20:8682 @0x4a21458/0x498b750))
(const_int -12 [0xfff4]))
where memrefs_conflict_p doesn't handle MINUS but wouldn't in this case
get to expansion of either VALUE anyway. But you can also see that
again a MEM_EXPR is mssing from the second MEM. Those are the push
instructions
(insn/f 38 5 39 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":13:1 60
{*pushsi2}
(nil))
(insn/f 40 39 41 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 3 bx))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":13:1 60
{*pushsi2}
where while spills use a special spill-slot decl the frame setup code
doesn't do anything like that so any MEM_EXPR based disambiguation
fails.
It's a bit hard to follow var-tracking in what insns it exactly sees to
disambiguate, as the frame setup code uses no MEM_EXPR and alias set zero
it seems to want to avoid any kind of disambiguation but at the same time
we can see the argp based accesses as to be non-conflicting?
The testcase has the variable sized stack allocation which now falls through
the cracks as being discovered as "stack-based" but as we're not
accessing it but only need the actual stack value it's odd we go to
true_dependence_1 for this.
[Bug debug/113562] [14 Regression] FAIL: gcc.dg/guality/pr54796.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Last reconfirmed||2024-01-24
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |14.0
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
With -m32 only. Code generated is
Dump of assembler code for function foo:
0x080483ef <+0>: push %ebp
0x080483f0 <+1>: mov%esp,%ebp
0x080483f2 <+3>: push %ebx
0x080483f3 <+4>: sub$0x4,%esp
0x080483f6 <+7>: mov0xc(%ebp),%eax
0x080483f9 <+10>:add$0xf,%eax
0x080483fc <+13>:and$0xfff0,%eax
0x080483ff <+16>:sub%eax,%esp
0x08048401 <+18>:mov%esp,%ebx
0x08048403 <+20>:sub$0x8,%esp
0x08048406 <+23>:push $0x2
0x08048408 <+25>:push %ebx
0x08048409 <+26>:call 0x80483e6
=> 0x0804840e <+31>:add$0x8,%esp
0x08048411 <+34>:push $0x4
0x08048413 <+36>:push %ebx
0x08048414 <+37>:call 0x80483e6
0x08048419 <+42>:add$0x10,%esp
0x0804841c <+45>:mov-0x4(%ebp),%ebx
0x0804841f <+48>:leave
0x08048420 <+49>:ret
the PC is where the function arguments and the 'c' stack local are no
longer visible to gdb. Code generation without the changes is the same
so it's very likely var-tracking that is affected by the alias analysis
changes possibly no longer disambiguating stack operations. In fact
after the
push $0x2
the variables are gone (I would have expected the call here). The
pushes are
(insn 22 21 23 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [2 S4 A32])
(const_int 2 [0x2]))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":16:3 60
{*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil)))
(insn 23 22 24 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(reg/f:SI 3 bx [108]))
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":16:3 60
{*pushsi2}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
but the SP operation that's likely problematical is the feeding
(insn 16 15 17 2 (parallel [
(set (reg/f:SI 7 sp)
(minus:SI (reg/f:SI 7 sp)
(reg:SI 0 ax [107])))
(clobber (reg:CC 17 flags))
])
"/space/rguenther/src/gcc/gcc/testsuite/gcc.dg/guality/pr54796.c":15:8 361
{*subsi_1}
(expr_list:REG_DEAD (reg:SI 0 ax [107])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
but we must come here via VALUE and
if (cselib_sp_based_value_p (val))
return static_reg_base_value[STACK_POINTER_REGNUM];
should still deal with this then (var-tracking sets this flag).
