On 09/06/2017 10:17 AM, Richard Henderson wrote:
>> Yea. I'd also expect zero/nonzero bits tracking in combine to catch
>> this. Shouldn't the sign bit be known to be zero after the shift which
>> makes the extension redundant regardless of the SUBREG_PROMOTED flag?
> You're right, this should be irrelevant. Any anyway combine should be
> constrained by modes, so it should require the SIGN_EXTEND to be present just
> to make the modes match up. Perhaps this test case is being suppressed
> because
> of something else, e.g. failure to combine insns when a hard-reg is involved?
It turns out that combine would like to match
(set (reg:DI 75)
(zero_extract:DI (reg:DI 10 a0 [ rs1 ])
(const_int 8 [0x8])
(const_int 24 [0x18])))
which seems reasonable enough to add as a pattern
(define_code_iterator any_extract [sign_extract zero_extract])
(define_code_attr [(sign_extract "sra") (zero_extract "srl")])
(define_insn "*<optab>_si_high"
(set (match_operand:DI 0 "register_operand" "=r")
(any_extract:DI
(match_operand:DI 1 "register_operand" "r")
(match_operand:DI 2 "const_int_operand" "")
(match_operand:DI 3 "const_int_operand" "")))
"TARGET_64BIT
&& INTVAL (operand[3]) > 0
&& INTVAL (operand[2]) + INTVAL (operand[3]) == 32"
"<insn>w\t%0,%1,%3"
[(set_attr "type" "shift")
(set_attr "mode" "SI")])
r~
