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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
