https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the first difference is
@@ -4076,36 +4076,47 @@
fbt (0x7ffff700b468: (reg/f:SI 16 argp)) == (address:SI -4)
fbt (0x7ffff71f6a68: (plus:SI (minus:SI (value/u/j:SI 13:4329
@0x4a213b0/0x498b
600)
(value/u:SI 20:8682 @0x4a21458/0x498b750))
- (const_int -12 [0xfffffffffffffff4]))) == (address:SI -1)
-bac false
+ (const_int -12 [0xfffffffffffffff4]))) == (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 [0xfffffffffffffff4]))
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.
