[PATCH] D40023: [RISCV] Implement ABI lowering

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

Thanks Eli, that saved me some time - fixed in https://reviews.llvm.org/rL322514 (clang-x86_64-linux-selfhost-modules-2 is now green).



================
Comment at: lib/CodeGen/TargetInfo.cpp:8913
+  }
+  return getNaturalAlignIndirect(Ty, /*ByVal=*/true);
+}
----------------
efriedma wrote:
> asb wrote:
> > efriedma wrote:
> > > asb wrote:
> > > > efriedma wrote:
> > > > > The spec says "Aggregates larger than 2✕XLEN bits are passed by reference and are replaced in the argument list with the address".  That's not byval.
> > > > The LLVM backend lowers byval in that way. Given that at this point we have a trivial data type (plain struct or similar) which is copied-by-value by C semantics, the only difference is whether the generated IR indicates implicit copying with 'byval' or relies on the caller explicitly doing the copy. For some reason I thought 'byval' was preferred, but looking again it seems uncommon to do it this way. I've changed it to false - thanks for spotting this.
> > > "byval" generally means the value is memcpy'ed into the argument list (so there is no pointer in the argument list). This is useful for handling C calling conventions which allow excessively large structs to be passed in the argument list, so the backend can emit a memcpy rather than expanding the operation into straight-line code.  The RISCV backend handling of byval is wrong, in the sense that it isn't consistent with what any other backend does.
> > > 
> > > This isn't relevant to the RISC-V C calling convention, but you should probably fix the backend at some point to avoid future confusion.
> > If I understand your concern correctly, it's that the RISCV backend passes a pointer to the byval copied argument rather than passing it direct on the stack? Isn't that consistent with what the Sparc, Lanai and the PPC backends do? It also seems consistent with my reading of the description of the byval attribute in the langref - a hidden copy is made. Whether that hidden copy is passed direct or a pointer to it is passed (which is consistent with the RISC-V calling convention for large values) seems an orthogonal concern.
> I can see SPARC does in fact pass byval arguments like you said (and I'll assume Lanai behaves the same way).  PowerPC doesn't, though, as far as I can tell (there are a bunch of PowerPC variants, but at least the 64-bit Linux ABI requires byval to pass arguments directly).
> 
> Yes, how exactly arguments are passed is not visible to the optimizer, and therefore is formally outside the scope of LangRef, but a byval which doesn't pass arguments directly is essentially useless.
I was looking at `PPCTargetLowering::LowerCall_32SVR4`, seems it's different for PPC64 as you say.


Repository:
  rL LLVM

https://reviews.llvm.org/D40023