From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22830 invoked by alias); 20 Nov 2014 03:51:53 -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 22794 invoked by uid 48); 20 Nov 2014 03:51:46 -0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/63986] New: [5 Regression][SH] gcc.target/sh/pr51244-15.c failures Date: Thu, 20 Nov 2014 03:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcctarget Message-ID: 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: 2014-11/txt/msg02132.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986 Bug ID: 63986 Summary: [5 Regression][SH] gcc.target/sh/pr51244-15.c failures Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh Starting with r217496 the SH specific test cases in gcc.target/sh/pr51244-15.c are failing. The reason for this is that, e.g. a function such as typedef char bool; int test_0 (int a, int b, int c, int* d) { bool x = a == 0; d[2] = !x; return x ? b : c; } with -O2 -m4 compiles to: tst r4,r4 <<< test against zero mov #-1,r1 negc r1,r1 tst r4,r4 <<< redundant test against zero bt/s .L5 mov.l r1,@(8,r7) mov r6,r5 .L5: rts mov r5,r0 and the expected result is: tst r4,r4 <<< only one test against zero movt r0 xor #1,r0 bt/s .L4 mov.l r0,@(8,r7) mov r6,r5 .L4: rts mov r5,r0 Before r217496 there are the following insns before the combine pass that are used to do the test against zero and store the inverted and non-inverted test result in a reg: (insn 11 6 14 2 (set (reg:SI 147 t) (eq:SI (reg/v:SI 167 [ a ]) (const_int 0 [0]))) sh_tmp.cpp:55 17 {cmpeqsi_t} (expr_list:REG_DEAD (reg/v:SI 167 [ a ]) (nil))) (insn 14 11 15 2 (set (reg:SI 163 [ D.1480 ]) (zero_extend:SI (subreg:QI (reg:SI 147 t) 0))) sh_tmp.cpp:55 398 {movt} (expr_list:REG_DEAD (reg:SI 147 t) (nil))) (insn 15 14 16 2 (set (reg:SI 173) (xor:SI (reg:SI 163 [ D.1480 ]) (const_int 1 [0x1]))) sh_tmp.cpp:56 138 {*xorsi3_compact} (nil)) (insn 16 15 17 2 (set (reg:SI 174) (zero_extend:SI (subreg:QI (reg:SI 173) 0))) sh_tmp.cpp:56 224 {*zero_extendqisi2_compact} (expr_list:REG_DEAD (reg:SI 173) (nil))) combine then uses the following pattern from sh.md: Trying 14 -> 15: Successfully matched this instruction: (parallel [ (set (reg:SI 173) (xor:SI (reg:SI 147 t) (const_int 1 [0x1]))) (set (reg:SI 163 [ D.1480 ]) (zero_extend:SI (subreg:QI (reg:SI 147 t) 0))) ]) which is then split into the appropriate/expected insn sequence. After r217496 the insns before combine look like: (insn 11 6 12 2 (set (reg:SI 147 t) (eq:SI (reg/v:SI 166 [ a ]) (const_int 0 [0]))) sh_tmp.cpp:56 17 {cmpeqsi_t} (nil)) (insn 13 12 14 2 (parallel [ (set (reg:SI 171 [ D.1480 ]) (xor:SI (reg:SI 147 t) (const_int 1 [0x1]))) (set (reg:SI 147 t) (const_int 1 [0x1])) (use (reg:SI 172)) ]) sh_tmp.cpp:56 400 {movrt_negc} (expr_list:REG_DEAD (reg:SI 172) (expr_list:REG_UNUSED (reg:SI 147 t) (nil)))) (insn 15 14 7 2 (set (reg:SI 147 t) (eq:SI (reg/v:SI 166 [ a ]) (const_int 0 [0]))) sh_tmp.cpp:57 17 {cmpeqsi_t} (expr_list:REG_DEAD (reg/v:SI 166 [ a ]) (nil))) and combine does not try the parallel pattern above. I've briefly tried working around the issue with some combine bridge patterns, but without any success. A possible solution could be adding some extra code to the movrt_negc splitter which looks at the surrounding insn and splits into a movt-xor sequence if required. However, I'd like to wait a bit until other pending combine patches have been installed.