Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> So it's not easily possible the within current infrastructure. But it does >> look >> like ARM might eventually benefit from something like STV on x86? >> > > I'm not sure. The problem with trying to do this in RTL is that you'd have > to be > able to decide from two psuedos whether they come from extracts that are > sequential. When coming in from a hard register that's easy yes. When coming > in > from a load, or any other operation that produces psuedos that becomes harder.
Yeah. Just in case anyone reading the above is tempted to implement STV for AArch64: I think it would set a bad precedent if we had a paste-&-adjust version of the x86 pass. AFAIK, the target capabilities and constraints are mostly modelled correctly using existing mechanisms, so I don't think there's anything particularly target-specific about the process of forcing things to be on the general or SIMD/FP side. So if we did have an STV-ish thing for AArch64, I think it should be a target-independent pass that uses hooks and recog, even if the pass is initially enabled for AArch64 only. (FWIW, on the patch itself, I tend to agree that this is really an SLP optimisation. If the vectoriser fails to see the benefit, or if it fails to handle more complex cases, then it would be good to try to fix that.) Thanks, Richard
