This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Support RVP vectors in the calling convention
AbandonedPublic

Authored by Jim on May 13 2021, 10:12 PM.

Details

Summary

Vectors in RVP are passed via GPRs. It can reuse the same
allocation rules as XLen to pass via registers or via the stack.

Diff Detail

Event Timeline

Jim created this revision.May 13 2021, 10:12 PM
Jim requested review of this revision.May 13 2021, 10:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 13 2021, 10:12 PM

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

Is this the right place to do it, or should it be done in Clang with bitcasts to/from integers?

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?

Jim added a comment.May 20 2021, 1:45 AM

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

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.

Jim abandoned this revision.Jun 4 2021, 4:51 AM