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

[Richard Sandiford <richard.sandiford@arm.com>]

Jakub Jelinek <jakub@redhat.com> writes:
> On Tue, Oct 27, 2020 at 11:13:21AM +0000, Richard Sandiford via Gcc-patches wrote:
>> Sorry to stick my oar in, but I think we should reconsider the
>> bcst_mem_operand approach.  It seems like these patches (and the
>> previous one) are fighting against the principle that operands
>> cannot be arbitrary expressions.
>
> Many operands already are fairly complex expressions, so it is unclear how
> this changes that.

But the things subject to constraint matching currently have to be
SCRATCHes, SUBREGs, REGs, MEMs or constants.  The address inside
a MEM can be complex, but even that has certain limits (so that LRA
knows what to do with addresses that need reloading).

Matching something like VEC_DUPLICATE in a constraint is new in
that thing being constrained isn't conceptually an object
(only the operand of the VEC_DUPLICATE is).

> And LRA etc. already handles SUBREGs of MEM which is kind of similar to
> this.

Yeah, but SUBREGs of MEMs are a bit of a legacy feature :-)
It would be great to remove them at some point…

>> This kind of thing was attempted long ago (even before my time!)
>> for SIGN_EXTEND on MIPS.  It ended up causing more problems than
>> it solved and in the end it had to be taken out.  I'm worried that
>> we might end up going through the same cycle again.
>> 
>> Also, this LRA code is extremely performance-sensitive in terms
>> of compile time: it's often at the top or near the top of the profile.
>> So adding calls to new functions like extract_mem_from_operand for
>> a fairly niche case probably isn't a good trade-off.
>
> It can be just an inline function that looks through just the target
> selected rtxes rather than arbitrary ones (derived from *.md properties or
> something).

Having something in the .md file sounds good.  The more information the
generators have, the more chance they have to do something efficient.

>> I think we should instead find a nice(?) syntax for generating separate
>> patterns for the two bcst_vector_operand alternatives from a single
>> .md pattern.  That would fit the existing model much more closely.
>
> That would result in thousands of new patterns, I'm not sure it is a good
> idea.  Pretty much all AVX512* instructions allow those.

Yeah, I hadn't realised that.

Thanks,
Richard