Jakub Jelinek <ja...@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
