ifcvt: Check for asm goto at the end of then_bb/else_bb in ifcvt [PR103908]
authorJakub Jelinek <jakub@redhat.com>
Thu, 6 Jan 2022 08:29:34 +0000 (09:29 +0100)
committerJakub Jelinek <jakub@redhat.com>
Thu, 6 Jan 2022 08:29:34 +0000 (09:29 +0100)
commit80ad67e2af0620d58d57d0406dc22693cf5b8ca9
tree94bf1238eefebddbf7463608ac34c687b92e66f0
parent1935db296892bbd9fc597889237528bd7e080ab1
ifcvt: Check for asm goto at the end of then_bb/else_bb in ifcvt [PR103908]

On the following testcase, RTL ifcvt sees then_bb
(note 7 6 8 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 8 7 9 3 (set (mem/c:SI (symbol_ref:DI ("b") [flags 0x2]  <var_decl 0x7fdccf5b0cf0 b>) [1 b+0 S4 A32])
        (const_int 1 [0x1])) "pr103908.c":6:7 81 {*movsi_internal}
     (nil))
(jump_insn 9 8 13 3 (parallel [
            (asm_operands/v ("# insn 1") ("") 0 []
                 []
                 [
                    (label_ref:DI 21)
                ] pr103908.c:7)
            (clobber (reg:CC 17 flags))
        ]) "pr103908.c":7:5 -1
     (expr_list:REG_UNUSED (reg:CC 17 flags)
        (nil))
 -> 21)
and similarly else_bb (just with a different asm_operands template).
It checks that those basic blocks have a single successor and
uses last_active_insn which intentionally skips over JUMP_INSNs, sees
both basic blocks contain the same set and merges them (or if the
sets are different, attempts some other noce optimization).
But we can't assume that the jump, even when it has only a single successor,
has no side-effects.

The following patch fixes it by punting if test_bb ends with a JUMP_INSN
that isn't onlyjump_p.

2022-01-06  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/103908
* ifcvt.c (bb_valid_for_noce_process_p): Punt on bbs ending with
asm goto.

* gcc.target/i386/pr103908.c: New test.
gcc/ifcvt.c
gcc/testsuite/gcc.target/i386/pr103908.c [new file with mode: 0644]