[llvm] [NVPTX] Generalize and extend upsizing when lowering 8/16-bit-element vector loads/stores (PR #119622)

Drew Kersnar via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 12 16:39:53 PST 2024


dakersnar wrote:

I just noticed and patched an edge case I had missed: ld.global.nc gets Selected via a different path, and the code was written with the assumption that v4i8 would never be a subvector of a larger vector. I pushed the simplest fix with my most recent commit, plus the test cases that were crashing, but I can also refactor the handling in tryLDGLDU to match what we do in tryLoadVector if you all think it would be a good idea. We could even have it generate `b32` instead of `u32` if we want to be consistent, although maybe that's too much churn.

Any other edge cases you can think of that I may have missed? I can scan through every use of v4i8 in the backend to see if anything seems equally fragile.

https://github.com/llvm/llvm-project/pull/119622


More information about the llvm-commits mailing list