On 7/25/23 17:05, Palmer Dabbelt wrote:
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?
It's a bit messy to say the least. However, we can look at other ports
and after doing so I'm less sure my concern is valid.
Take the typical movXX pattern or expander. Both operands have a mode,
so things like CONST_INT must be passing through, even though they're
VOIDmode.
So it's probably a non-issue.
jeff
