[PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint.

[Hongtao Liu]

On Fri, Oct 30, 2020 at 1:00 AM Richard Sandiford
<richard.sandiford@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