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

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added inline comments.


================
Comment at: llvm/lib/Target/SystemZ/SystemZCallingConv.td:286
+    CCIfType<[v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
+             CCAssignToStack<16, 8>>>
+]>;
----------------
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.


================
Comment at: llvm/lib/Target/SystemZ/SystemZCallingConv.td:193
+  // F4D and F6D, hence F4Q, are provided for ABI non-compliant code.
+  CCIfType<[f128], CCAssignToReg<[F0Q,F4Q]>>,
+
----------------
kpn wrote:
> uweigand wrote:
> > Space after ','.
> What is this ABI non-compliant code that's getting support?
> 
> How does a long double complex get returned?
Non ABI-compliant code here refers to LLVM front-ends other than clang, e.g. for languages other than C/C++ or for JIT use cases.  Some of those use cases require multiple return values to be passed efficiently.  While you could require any such users to define their own calling convention for that, this is quite tedious (and requires back-end changes).   Therefore, it most LLVM back-ends provide an extension in their "default" calling convention for multiple return values, which is never used by LLVM IR generated by clang, but is available for these other use case.

However, if it is indeed true that in XPLINK, the C/C++ complex long double is already returned in four FPRs, then that would **not** could as "non ABI-compliant" use.  But that's just a comment wording issue.


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

https://reviews.llvm.org/D101010