Vectors in RVP are passed via GPRs. It can reuse the same
allocation rules as XLen to pass via registers or via the stack.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Is this the right place to do it, or should it be done in Clang with bitcasts to/from integers?
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
6800 | Unnecessary parens |
Personally, I think it's okay to do this here as it's likely we'll have the vector types in IR when coming from ABIs like SPIR or SPIR-V. At least, that was the justification for the V vectors. I know what you mean, though. I don't know if the authors anticipate a similar use-case for the P extension.
As mentioned, I think this patch is missing test cases for vector types smaller or larger than XLEN.
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
6803 | Can this else ever fall through with P? What if you passed <4 x i64>? Should P ensure that vectors are correctly broken down into XLen-sized part vectors? |
I did the experiments that vector type arguments have been passed as XLenVT. And it is bitcasted back to vector type before using.
typedef signed char int8x4_t __attribute((vector_size(4))); int8x4_t foo1(int8x4_t a, int8x4_t b) { return a + b; }
And its dag looks like:
t4: i32,ch = CopyFromReg t0, Register:i32 %1 t6: v4i8 = bitcast t4 t2: i32,ch = CopyFromReg t0, Register:i32 %0 t5: v4i8 = bitcast t2 t7: v4i8 = add t6, t5
It is my mistake. This patch is unneeded. How do you think? @frasercrmck
Sure, if this XLenVT use-case works better for you then I don't see a point in adding unused code. We can revisit if there's another reason to support vectors directly in IR.
clang-tidy: error: no member named 'hasStdExtP' in 'llvm::RISCVSubtarget' [clang-diagnostic-error]
not useful