[PATCH] D137504: [PowerPC] Implement 64-bit ELFv2 Calling Convention in TableGen (for integers/floats/vectors in registers)

Amy Kwan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 27 06:33:26 PDT 2023


amyk added inline comments.


================
Comment at: llvm/test/CodeGen/PowerPC/GlobalISel/irtranslator-args-lowering.ll:79
   ; CHECK: bb.1.entry:
-  ; CHECK:   liveins: $f1, $x3, $x4, $x5, $x6
+  ; CHECK:   liveins: $f1, $x3, $x5, $x6, $x7
   ; CHECK:   [[COPY:%[0-9]+]]:_(s64) = COPY $x3
----------------
nemanjai wrote:
> amyk wrote:
> > stefanp wrote:
> > > This is interesting because we are changing the way that a struct is being passed in registers.
> > > Which of these set of liveins is correct?
> > > 
> > > My understanding of the ABI (and I could be wrong here so please read and make sure) is that non-homogeneous structs are passed as a block of memory. For example the `i8` and `float` would be in `R3` at the same time.
> > > So, it might look something like this:
> > > ```
> > > R3 -> i8, float
> > > R4 -> i32, i32
> > > R5 -> i32
> > > ``` 
> > >  If we look at it that way we should only be using `R3`, `R4`, `R5`.
> > > 
> > > Either way, I think it is important to look at this and figure out why it changes and what the ABI says.
> > I count be misunderstanding this as well but when reading the ABI initially, I understood it the same as you described in your comment where we would be utilizing r2, r4 and r5 for this particular struct. 
> > 
> > Essentially, I thought that both the original and updated `liveins` is incorrect, just because this implementation is meant to handle simple cases of integers, floats and vectors within registers and doesn't fully support structs yet. I thought I had put a comment denoting this before but it turns out that I didn't, so thank you for pointing this out, Stefan. 
> > 
> > I can definitely add the TODO here, and we can plan to add support for structs in a follow up patch at a later time. I also just wanted to check with @nemanjai if this is a reasonable approach for this patch.
> One easy way to resolve this is to compile something with current compilers that accesses the members from Stefan's example and see which register they're expected to be in.
> 
> Also, if we happen to do the wrong thing for GlobalISel for now for passing structs, I'm perfectly fine with marking it as a TODO to fix it later.
Sounds good. I have added a TODO when I committed the patch. The correct way appears to be what Stefan has outlined/what was discussed (R3, R4, R5).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137504



More information about the llvm-commits mailing list