[PATCH] D49464: [COFF, ARM64] Mark only POD-type returns as SRET

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 19 10:27:10 PDT 2018


rnk added a comment.

I think you may want to use a different IR convention to indicate whether X0 or X8 should be used for the pointer to the returned struct. My first thought is to use `inreg` to indicate that the struct is POD and X8 should be used, and that it does not need to be preserved. In AArch64ABIInfo, you would check for POD-ness and use ABIArgInfo::getIndirectInReg instead of ABIArgInfo::getIndirect.

We should also think about the best way to represent the fact that the address of a non-POD return value must be returned in X0. For X86, the `sret` attribute is used to communicate this requirement. Another alternative would be to change the LLVM IR function return type to a pointer type and add the LLVM IR `returned` attribute to the argument with the address of the return value. If we decide not to go with `sret` + `inreg`, we need to do this anyway, since the backend has no way of knowing it needs to preserve X0.



================
Comment at: lib/CodeGen/CGCall.cpp:1988
+    if (getTarget().getTriple().isOSWindows() &&
+        getTarget().getTriple().getArch() == llvm::Triple::aarch64) {
+      const CXXRecordDecl *RD = FI.getReturnType()->getAsCXXRecordDecl();
----------------
yinma wrote:
> efriedma wrote:
> > We shouldn't be checking the triple here.  Can we extend CGFunctionInfo to record this instead, then perform the check in AArch64ABIInfo in lib/CodeGen/TargetInfo.cpp?
> One thing we can do is to add a new ABIKind in AArch64ABIInfo, and test it as the condition 
ABIKind is an implementation detail of AArch64ABIInfo. I'm not sure how we would use that here.


https://reviews.llvm.org/D49464





More information about the llvm-commits mailing list