On Fri, 21 Jul 2023 11:47:58 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On 7/21/23 12:31, Palmer Dabbelt wrote:
(define_expand "len_mask_gather_load<VNX1_QHSD:mode><VNX1_QHSDI:mode>"
[(match_operand:VNX1_QHSD 0 "register_operand")
- (match_operand 1 "pmode_reg_or_0_operand")
+ (match_operand:P 1 "pmode_reg_or_0_operand")
(match_operand:VNX1_QHSDI 2 "register_operand")
(match_operand 3 "<VNX1_QHSD:gs_extension>")
(match_operand 4 "<VNX1_QHSD:gs_scale>")
a bunch of times, as there's a ton of them? I'm not entirely sure if that
could manifest as an actual bug, though...
But won't this cause (const_int 0) to no longer match because CONST_INT
nodes are modeless (VOIDmode)?
I poked around a bit and I'm not actually sure, I'm kind of lost on the docs
here. IIUC we're eliding the VOIDmode in the predicate correctly
(define_predicate "const_0_operand"
(and (match_code "const_int,const_wide_int,const_vector")
(match_test "op == CONST0_RTX (GET_MODE (op))")))
so we're OK there, otherwise we'd presumably have similar problems with
expanders like
(define_expand "subsi3"
[(set (match_operand:SI 0 "register_operand" "= r")
(minus:SI (match_operand:SI 1 "reg_or_0_operand" " rJ")
(match_operand:SI 2 "register_operand" " r")))]
""
which we have a few of -- though it'd be kind of a silent failure, as
presumably we'd just end up with some more move-x0s emitted?
