http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-12-19 
18:34:16 UTC ---
I believe this is just because of very weird target avr stuff, either it is a
target bug that can be fixed up in the backend somehow, or perhaps would need
some middle-end help, but still it is avr specific.
Doesn't seem to have anything to do with PR49330.

The problem seems to be that the prologue here looks like:
(insn/f 43 7 44 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1
A8])
        (reg:QI 28 r28)) pr50063.c:9 -1
     (nil))
(insn/f 44 43 45 2 (set (mem/c:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [5 S1
A8])
        (reg:QI 29 r29)) pr50063.c:9 -1
     (expr_list:REG_DEAD (reg:QI 29 r29)
        (nil)))
(insn 45 44 46 2 (set (reg/f:HI 28 r28)
        (reg/f:HI 32 __SP_L__)) pr50063.c:9 -1
     (nil))
(insn/f 46 45 47 2 (set (reg/f:HI 28 r28)
        (plus:HI (reg/f:HI 28 r28)
            (const_int -12 [0xfffffffffffffff4]))) pr50063.c:9 -1
     (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28)
            (plus:HI (reg/f:HI 32 __SP_L__)
                (const_int -12 [0xfffffffffffffff4])))
        (nil)))
(insn 47 46 48 2 (set (reg/f:HI 32 __SP_L__)
        (reg/f:HI 28 r28)) pr50063.c:9 -1
     (nil))

where reg 28 is frame pointer and reg 32 is stack pointer.  When
canon_true_dependence is called by DSE, one of the mem addresses is r28 plus
CONST_INT, the other is a VALUE, which is in the end a VALUE of r28 plus some
offset.  But r28 (frame pointer) and r32 (stack pointer) have the same VALUE in
this case, and because of the initialization of sp from fp r32 is actually
before r28 in that VALUE's locs list.  So, find_base_term for that VALUE
returns (address r32), while find_base_term for r28 plus CONST_INT doesn't use
cselib values at all and thus returns (address r28) and base_alias_check just
fails.  The question is why avr does this, and if it really has to do that, it
should make sure somehow that for the alias analysis either REG_BASE_VALUE of
r28 is the same as REG_BASE_VALUE of r32.  E.g. it could define FIND_BASE_TERM
and do something for r28/r32 if they are known to be the same.
init_alias_analysis ignores prologue and epilogue insns after reload, which is
probably why record_set isn't called here on the r32 = r28 set.

Reply via email to