From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6111 invoked by alias); 29 Jun 2010 16:57:07 -0000 Received: (qmail 5949 invoked by uid 48); 29 Jun 2010 16:56:48 -0000 Date: Tue, 29 Jun 2010 16:57:00 -0000 Message-ID: <20100629165648.5948.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/44707] operand requires impossible reload In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "uweigand at gcc dot gnu dot org" 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: 2010-06/txt/msg02833.txt.bz2 ------- Comment #1 from uweigand at gcc dot gnu dot org 2010-06-29 16:56 ------- I agree, this looks like a longstanding bug in rs6000_legitimize_reload_address. What happens here is that find_reloads is called on this insn: (insn 15 8 18 2 pr44707.c:13 (asm_operands/v ("/* %0 %1 %2 %3 %4 */") ("") 0 [ (mem/s/c:SI (symbol_ref:SI ("v") [flags 0xc0] ) [3 v.a+0 S4 A32]) (mem/c/i:SI (symbol_ref:SI ("w") [flags 0xc4] ) [3 w+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 4 [0x4]))) [3 v.b+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 8 [0x8]))) [3 v.c+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 12 [0xc]))) [3 v.d+0 S4 A32]) ] [ (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) ] [] pr44707.c:14) -1 (nil)) rs6000_find_reloads_address notices that it can rewrite (symbol_ref:SI "v") to (lo_sum:SI (high:SI (symbol_ref:SI "v")) (symbol_ref:SI "v")) (and place a reload on the (high:SI) subexpression) and does so. This change remains in the insn, and when in the next iteration find_reloads is called again, the insn now looks like: (insn 15 8 18 2 pr44707.c:13 (asm_operands/v ("/* %0 %1 %2 %3 %4 */") ("") 0 [ (mem/s/c:SI (lo_sum:SI (high:SI (symbol_ref:SI ("v") [flags 0xc0] )) (symbol_ref:SI ("v") [flags 0xc0] )) [3 v.a+0 S4 A32]) (mem/c/i:SI (lo_sum:SI (high:SI (symbol_ref:SI ("w") [flags 0xc4] )) (symbol_ref:SI ("w") [flags 0xc4] )) [3 w+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 4 [0x4]))) [3 v.b+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 8 [0x8]))) [3 v.c+0 S4 A32]) (mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI ("v") [flags 0xc0] ) (const_int 12 [0xc]))) [3 v.d+0 S4 A32]) ] [ (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) (asm_input:SI ("nro") (null):0) ] [] pr44707.c:14) -1 (nil)) However, this expression is now no longer recognized by rs6000_legitimize_reload_address, and therefore no reload on (high:SI) is pushed. Thus, when the reload is finally processed, a reload insn like this is generated: (insn 26 8 27 2 pr44707.c:13 (set (reg:SI 10 10) (lo_sum:SI (high:SI (symbol_ref:SI ("v") [flags 0xc0] )) (symbol_ref:SI ("v") [flags 0xc0] ))) -1 (nil)) As this does not actually correspond to any valid pattern, an assertion is triggered. The underlying problem is that with the current reload setup, an implementation of LEGITIMATE_RELOAD_ADDRESS must always recognize expressions it has itself generated in an earlier call. And indeed, that's what a comment in rs6000_legitimize_reload_address says: static rtx rs6000_legitimize_reload_address (rtx x, enum machine_mode mode, int opnum, int type, int ind_levels ATTRIBUTE_UNUSED, int *win) { bool reg_offset_p = reg_offset_addressing_ok_p (mode); /* We must recognize output that we have already generated ourselves. */ if (GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 0)) == PLUS && GET_CODE (XEXP (XEXP (x, 0), 0)) == REG && GET_CODE (XEXP (XEXP (x, 0), 1)) == CONST_INT && GET_CODE (XEXP (x, 1)) == CONST_INT) However, this recognizes only certain types of such output, and in particular not the one that shows up in this test case. It seems to me that simply extending rs6000_legitimate_reload_address to handle this case as well should fix the bug. -- uweigand at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2010-06-29 16:56:47 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707