http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54921
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-23
11:21:55 UTC ---
Looks to be cselib + find_base_term related.
We have:
49 bp=sp
50 sp=sp-0x30
...
46 r8=bp-0x30
47 r9=r8+0x4
...
43 di=r9
17 {cx=0;di=cx<<0x2+di;[di]=0;use ax;...}
18 [bp-0x2c]=si
The reason for insn 46 and 47 being separate is that r8 is used later on.
When sched-deps.c asks whether there is any output_dependence in between
the insn 17 (rep_stossi) and insn 18 stores, it returns that there is not, even
when there is. This is because the bp-0x2c store is value:2 - 0x2c, where
find_base_term (value:2) is (address:DI -4), i.e. HFP base, while when calling
find_base_term on the value for di (== r9), it uses the loc value of r8 + 4
and value of r8 has sp register among its locs (in addition to value:2 - 0x30),
so find_base_term on the value of di returns (address:DI -1), i.e. sp based,
and
thus base_alias_check returns 0.
I'm afraid if alias.c wants to argue that sp based accesses can't alias with
hfp based accesses with frame_pointer_needed, perhaps cselib.c needs to do what
I've done so far in var-tracking.c, in particular right after the assignment to
hard frame pointer in the prologue do cselib_invalidate_rtx
(stack_pointer_rtx);
so that sp based VALUEs don't have hfp anywhere in locs and similarly hfp based
VALUEs don't have sp anywhere in locs.
