From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19408 invoked by alias); 19 Dec 2011 18:35:03 -0000 Received: (qmail 19298 invoked by uid 22791); 19 Dec 2011 18:35:01 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Dec 2011 18:34:48 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c Date: Mon, 19 Dec 2011 18:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.3 X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg02147.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek 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.