On Fri, Oct 30, 2020 at 1:00 AM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> I guess my main objection is that we have a special memory constraint
> that isn't in fact matching a MEM (at least not directly). That seems
> odd and feels like it's going to come back to bite us.
>
> From an RTL perspective, the MEM in the bcst_memory_operand isn't that
> special. It's really just a normal memory that happens to appear in a
> VEC_DUPLICATE.
>
> With the MIPS thing, the SIGN_EXTEND was around a register rather
> than a memory, and the register constraints applied to the register
> as normal. In other words, the SIGN_EXTEND was not part of the
> constraint: target-independent code removed the SIGN_EXTEND
Yes, that's because target-independent code can't distinguish whether
SIGN_EXTEND is part of constraints. More specifically, constrain_operands
will swallow the unary operator when matching constraints. Cut from recog.c
-----
/* A unary operator may be accepted by the predicate, but it
is irrelevant for matching constraints. */
/* For special_memory_operand, there could be a memory operand inside,
and it would cause a mismatch for constraint_satisfied_p. */
if (UNARY_P (op) && op == extract_mem_from_operand (op))
op = XEXP (op, 0);
------
But a unary operator with memory would never be accepted by the predicate
unless it's corresponding to special_memory_constraint, because in IRA/LRA,
CT_MEMORY would never be matched when op is false for MEM_P.
> before matching against the constraints.
>
> I think we could view the bcst_mem_operand case in a similar way.
> The constraint process ends up having two steps: an extraction
> step (for the REG inside a SIGN_EXTEND for MIPS, for the MEM
> inside a VEC_DUPLICATE for AVX512) and the normal matching step on
> the result. This could either happen on a constraint-by-constraint
> basis or (perhaps more efficiently) as a separate step before
> applying the constraints. Not sure off-hand which is better,
> would need to think more about it.
>
> But I think this extraction process should be described directly in the
> .md file somehow. I've had a few ideas but I'm not happy enough with
> any of them yet to post.
>
> Thanks,
> Richard
--
BR,
Hongtao
