[Bug target/77822] [6 Regression] arm64 Error: immediate value out of range 0 to 63 at operand 3

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77822

--- Comment #20 from ktkachov at gcc dot gnu.org ---
One of the RTL sequences before combine showing the problem is:

(insn 94 93 95 18 (set (reg:DI 143)
        (const_int 160 [0xa0])) "bad.cpp":19 50 {*movdi_aarch64}
     (nil))
(insn 95 94 96 18 (set (reg:DI 144)
        (ashiftrt:DI (reg:DI 75 [ b.0_3 ])
            (subreg:QI (reg:DI 143) 0))) "bad.cpp":19 647
{*aarch64_ashr_sisd_or_int_di3}
     (expr_list:REG_DEAD (reg:DI 143)
        (expr_list:REG_EQUAL (ashiftrt:DI (reg:DI 75 [ b.0_3 ])
                (const_int -96 [0xffffffffffffffa0]))
            (nil))))
(insn 96 95 97 18 (set (reg:DI 145)
        (and:DI (reg:DI 144)
            (const_int 1 [0x1]))) "bad.cpp":19 470 {anddi3}
     (expr_list:REG_DEAD (reg:DI 144)
        (nil)))
(insn 97 96 98 18 (set (reg:CC 66 cc)
        (compare:CC (reg:DI 145)
            (const_int 0 [0]))) "bad.cpp":19 393 {cmpdi}
     (expr_list:REG_DEAD (reg:DI 145)
        (nil)))
(jump_insn 98 97 99 18 (set (pc)
        (if_then_else (eq (reg:CC 66 cc)
                (const_int 0 [0]))
            (label_ref:DI 105)
            (pc))) "bad.cpp":19 9 {condjump}
     (expr_list:REG_DEAD (reg:CC 66 cc)
        (int_list:REG_BR_PROB 5000 (nil)))



Some of the dubious combinations combine tries are:

Trying 94, 95 -> 96:
Successfully matched this instruction:
(set (reg:DI 145)
    (zero_extract:DI (reg:DI 75 [ b.0_3 ])
        (const_int 1 [0x1])
        (const_int 160 [0xa0])))


Trying 96 -> 97:
Failed to match this instruction:
(set (reg:CC_NZ 66 cc)
    (compare:CC_NZ (zero_extract:DI (reg:DI 75 [ b.0_3 ])
            (const_int 1 [0x1])
            (const_int 160 [0xa0]))
        (const_int 0 [0])))

Trying 96 -> 98:
Successfully matched this instruction:
(set (pc)
    (if_then_else (eq (zero_extract:DI (reg:DI 75 [ b.0_3 ])
                (const_int 1 [0x1])
                (const_int 160 [0xa0]))
            (const_int 0 [0]))
        (label_ref:DI 105)
        (pc)))


If I put a breakpoint at expand_compound_operation I already see arguments such
as:
(zero_extract:DI (reg:DI 75 [ b.0_3 ])
    (const_int 1 [0x1])
    (const_int 160 [0xa0]))

Given that the input is already dodgy (DImode shift by 160) I don't know
whether the subst or make_compound_operation
machinery in combine should be trying too hard to reject forming these
zero_extracts. Maybe something should be taking
SHIFT_COUNT_TRUNCATED into account?