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

[Neumann Hon via Phabricator via llvm-commits]

Everybody0523 marked 2 inline comments as done.
Everybody0523 added inline comments.


================
Comment at: llvm/lib/Target/SystemZ/SystemZCallingConv.td:211
+// space must be reserve for all the args on stack
+
+// 1           2           3              (register used, the 3 arg
----------------
kpn wrote:
> kpn wrote:
> > uweigand wrote:
> > > If you want to have a comment here describing how the ABI works in general terms, that's of course good, but I'm not sure if the long table here is particularly useful.  Maybe describing it in terms of rules would be better?   Or, even better, providing a link to an offical ABI doc?
> > The comment seems misleading. Integer types get expanded to fill a whole GPR. So passing three chars uses 3 registers -> 24 bytes. Talking about bytes therefore doesn't seem useful. Worse, it's misleading to refer to "bytes" for GPR and not for the FPR since it implies that parms get packed or something. I see that you addressed this below, but it'd be better to not even provoke the thought in someone reading the code. I'd stick with "registers" instead of "bytes" in this sentence.
> > 
> > One has to look closely at the table to see that FP parms can prevent a GPR from being used that would be used if there were no FP parms. So that bit could use a description in english. 
> > 
> > A link to the ABI doc would be useful, or at least the name of it. Since links go stale, the name is probably a minimum.
> > 
> > Actually, how about copying the tables that are (were?) in the ABI documentation? Last time I looked IBM had a list of examples showing how FP values can push around GPR values, and how large numbers of integer parms can prevent FP values from being passed in FP registers despite FP registers being available. (I admit it's been years since I looked at the documentation.)
> Now that I've looked at the current version of Vendor Interfaces, the table I was thinking of is in Appendix B, from pages 924 to 931. That's ... a lot.
> 
> Oh, and appendix B doesn't include the documentation that is elsewhere in the book. XPLINK calling conventions require that much documentation. So a reference to the documentation may be better than trying to duplicate it.
> 
> Ulrich, how about this: Instead of having this table below, and instead of trying to put 6-7 pages of documentation in comments here, how about a comment about how there are a number of common tricky cases and they're documented in <documentation bib entry here>?
I've updated the comments to include a note on when the full specification of the ABI can be found. 

I am hesitant to include a link for reason you mentioned above - links can go stale. Given the name of the document, it shouldn't be hard to find the latest version of the LE vendor interfaces.


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

https://reviews.llvm.org/D101010