[PATCH] D101010: [SystemZ] [z/OS] Add XPLINK64 Calling Convention to SystemZ

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand accepted this revision.
uweigand added a comment.
This revision is now accepted and ready to land.

So it looks like this is good to go now.   LGTM, thanks!



================
Comment at: llvm/lib/Target/SystemZ/SystemZCallingConv.td:235
+  // We need to deal with this first
+  CCIfType<[i64], CCCustom<"CC_SystemZ_I128Indirect">>,
+  // The first 3 integer arguments are passed in registers R1D-R3D.
----------------
Everybody0523 wrote:
> uweigand wrote:
> > Just to re-confirm: this handler will pass an i128 via implicit pointer (i.e. push the i128 to the stack somewhere outside the argument list, and pass a pointer to that location as argument).   Is that actually correct for XPLINK?  Reading the specs in the documentation referred to above, I get the impression that XPLINK never passes arguments via implicit pointers ...
> Yes, that's the intention. 
OK, thanks for confirming.


================
Comment at: llvm/lib/Target/SystemZ/SystemZCallingConv.td:286
+    CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
+             CCAssignToStack<16, 8>>>
+]>;
----------------
Everybody0523 wrote:
> uweigand wrote:
> > Note that the ELF calling convention makes special provisions for "short" vector types, i.e. those defined using attribute((vector_size(8))) or shorter.   They may be passed in VRs like the "normal" 16 byte vectors, but if none are available they'll **not** get passed in a normal 16-byte stack slot, but rather in an 8-byte stack slot.
> > 
> > I notice that this provision is not in place with the XPLINK convention.  Now I guess this is a decision for you to make, given that such types would be an extension to the ABI anyway.  I just wanted to make sure that this is **considered** choice and not just happening by accident.
> Hi Uli, we actually hadn't considered that - thank you for pointing this out. 
> 
> After thinking about it for a while I think we should keep the current behavior, ie. pass in a 16-byte stack slot. The reason for this is if were to copy the ELF behavior, and pass short vector types in a 8-byte stack slot if passed on the stack, we would have to do one of two things.
> 
> 
> # Have short vector types passed-by-register "shadow" 8 bytes in the argument area. However this would mean that vector registers can shadow a variable amount of space on the argument list depending of the type of the parameter contained within, which is very strange. 
> # Have short vector types passed-by-register "shadow" 16 bytes in the argument area, but those passed-by-stack occupy 8 bytes. This means that two params of the same type would occupy a different amount of memory in the argument list depending on whether it is passed-by-register or passed-by-stack - also very strange. 
I see, that does make sense to me as well.


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

https://reviews.llvm.org/D101010