https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119428
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess on SHIFT_COUNT_TRUNCATED targets one needs to avoid trying to extend a
shift or rotate to a wider mode because the masking of the shift count is
implicit.
Except that x86 is not a SHIFT_COUNT_TRUNCATED target, but handles such stuff
through splitters. Wonder if the masking in that case really shouldn't be
explicit in the IL, or at least explicit until end of combine, here it is split
already during combine
with
(define_split
[(set (match_operand:SWI 0 "register_operand")
(any_rotate:SWI
(match_operand:SWI 1 "const_int_operand")
(subreg:QI
(and
(match_operand 2 "int248_register_operand")
(match_operand 3 "const_int_operand")) 0)))]
"(INTVAL (operands[3]) & (GET_MODE_BITSIZE (<MODE>mode) - 1))
== GET_MODE_BITSIZE (<MODE>mode) - 1"
[(set (match_dup 4) (match_dup 1))
(set (match_dup 0)
(any_rotate:SWI (match_dup 4)
(subreg:QI (match_dup 2) 0)))]
"operands[4] = gen_reg_rtx (<MODE>mode);")
Apparently my fault in PR96226.
I guess we need to find out where this widening to zero_extract happens,
whether it considers SHIFT_COUNT_TRUNCATED etc.
