[PATCH] D104727: [RISCV] Permit RVV stack offsets larger than 12 bits

Thu Jun 24 06:35:47 PDT 2021

frasercrmck added a comment.

In D104727#2838057 <https://reviews.llvm.org/D104727#2838057>, @rogfer01 wrote:

>> Strictly speaking it's not 12-bit stack offsets we're now supporting but rather a 12-bit "number of vector registers". For whatever reason I was unable to find a concise way of explaining this in the commit message/description so if anyone's got a better way I'm all ears.
>
> I think "number of vector registers" may be good enough. This seems difficult to describe because the offsets in the scalable vector stackid have their offsets conceptually scaled to the smallest `vscale` possible (=1), so the code counts how many registers (currently 8 bytes per VR under `vscale=1`) are contained in (the unscaled) `Amount` to later scale that using `vlenb`.
>
> I'm curious when you hit this. Asking because, unless I'm reading the testcase wrong, you're computing a `NumOfVReg` that seems huge (3072?)
>
> Other than that LGTM. Thanks @frasercrmck

Yeah I suppose the code says it best: it's the number of VLEN-sized registers. I have no idea why I find this part of the code so unintuitive. Probably for the reason you describe.

As for how we reached this situation, I was really trying to "torture test" the code generator by really pushing the vectorization factor in our OpenCL implementation. Basically it ended up force-vectorizing kernels containing things like `<16 x i64>` up by `vscale x 16` and so was ending up with nonsensically wide vectors like `<vscale x 256 x i64>` which must of course spill. I'm not claiming that this is the sole reason as I've seen some particularly bad code generation even at the lower VFs (anything larger than `vscale x 1` can end up spilling even for small kernels). But yeah if there's ever a reason to spill a silly amount of registers, this'd be it. The good news is that this was the only failure I saw across the test suite!

The test case itself is just a pseudo-random number I chose that's higher than 2048 but isn't near a power of two (meaning it'd choose to shift) I haven't been through all the "real" failures: the only one I looked at was somewhere in the 2000s.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104727/new/

https://reviews.llvm.org/D104727