[Bug middle-end/120639] vect: Strided memory access type, stores with gaps?

[rdapp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639

--- Comment #1 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I'm just realizing that without knowing the stride statically, we'd generate a
lot of code as we don't have a way of setting an element size for loads
dynamically.  Although riscv offers a dynamic element size it does not apply to
loads/stores.

So it would look something like:

for (elsz : [64 32 16 8])
{
  while (i_width > elsz)
  {
     switch (elsz)
     {
        64:
          // code for 64-bit loads
        32:
          // code for 32-bit loads
        ...
     }
  }
}

Or swap outer and inner loop in order to interleave the loads.  One approach is
basically to re-vectorize the loop with decreasing element size and adjusted
datarefs, the other one is to interleave the element sizes for each individual
operation (load, arith, store) until i_width is reached. 

Masking doesn't help here as the intention is to load full elements.

For compile-time known strides we might at least not need all the overhead but
could only generate those element-size-loops we really need.

We would still need virtual vector modes (like e.g. V24QI) that could be
handled by the vectorizable_* functions via lowering.  That would be similar to
the interleaving above and would at least double the number of registers.

I'm just thinking out loud here, of course.  I didn't manage to convince myself
that anything of this is compelling :)