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.
And LRA etc. already handles SUBREGs of MEM which is kind of similar to
this.
> 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).
> 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.
Jakub
