From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12338 invoked by alias); 28 Sep 2015 16:27:02 -0000 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 Received: (qmail 12269 invoked by uid 48); 28 Sep 2015 16:26:58 -0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/64331] regcprop propagates registers noted as REG_DEAD Date: Mon, 28 Sep 2015 16:27:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: gjl at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_gcctarget cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg02196.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 Oleg Endo changed: What |Removed |Added ---------------------------------------------------------------------------- Target|avr |avr sh*-*-* CC| |olegendo at gcc dot gnu.org --- Comment #10 from Oleg Endo --- I've got a similar case on SH. In the file spacetab.c, when compiled with -O2 -m4 -ml there's a sequence: cmp/eq r3,r4 movt r3 movt r12 cmp/gt r0,r2 which should be rather (after scheduling): cmp/eq r3,r4 movt r3 cmp/gt r0,r2 mov r3,r12 The sequence can be caught with a simple peephole: (define_peephole2 [(set (match_operand:SI 0 "arith_reg_dest") (match_operand:SI 1 "t_reg_operand")) (set (match_operand:SI 2 "arith_reg_dest") (match_operand:SI 3 "t_reg_operand"))] "TARGET_SH1" [(set (match_dup 0) (reg:SI T_REG)) (set (match_dup 2) (match_dup 0))]) which doesn't work for some reason. So I thought maybe something like this: (define_peephole2 [(set (match_operand:SI 0 "arith_reg_dest") (match_operand:SI 1 "t_reg_operand")) (set (match_operand:SI 2 "arith_reg_dest") (match_operand:SI 3 "t_reg_operand"))] "TARGET_SH1" [(const_int 0)] { emit_insn (gen_movt (operands[0], get_t_reg_rtx ())); emit_move_insn (operands[2], operands[0]); DONE; }) which emits the insns in the peephole2 pass as intended, but regcprop changes them again into the undesired movt-movt sequence. So I've tried adding a REG_DEAD note to the first insn: (define_peephole2 [(set (match_operand:SI 0 "arith_reg_dest") (match_operand:SI 1 "t_reg_operand")) (set (match_operand:SI 2 "arith_reg_dest") (match_operand:SI 3 "t_reg_operand"))] "TARGET_SH1" [(const_int 0)] { add_reg_note (emit_insn (gen_movt (operands[0], get_t_reg_rtx ())), REG_DEAD, get_t_reg_rtx ()); emit_move_insn (operands[2], operands[0]); DONE; }) and it is still ignored. regcprop also doesn't look at any costs, so the only solution to "fix" this is searching and replacing insns manually in split4.