smithp35 wrote: To get more eyes on this I recommend posting the RFC, or at least a summary with a link to this PR on discourse as per the RFC process https://llvm.org/docs/RFCProcess.html
> On AArch64, __int256 passes arguments and return values in x0-x3 (4 GPRs). An > identity function compiles to a single ret. But the AAPCS may require > indirect passing for types >16 bytes (a 32-byte struct goes indirect). Is > direct register passing acceptable for a builtin scalar, or does AAPCS > conformance require indirect? I don't have the expertise to answer this. The current rule for composite types to be <= 16 bytes to be passed in core registers is a general purpose heuristic. As I understand it, the AAPCS does not allow a composite type to be half passed in registers and half passed on the stack, so there may be good reasons not to have large types eat up half of the argument registers, as this would only let 1 or 2 (assuming no other parameters) __int256 to be passed in registers anyway. A reasonable argument could be made for __int256 being special as it would not come up frequently in general purpose code, but we'd need to have that argument on the ABI if this were to become an ABI supported type implemented by GCC as well as clang. Please raise an issue with the ABI https://github.com/ARM-software/abi-aa/issues to discuss. That will make the GCC folks aware too. https://github.com/xroche/llvm-project/blob/add-int256-builtin-type/RFC-DRAFT.md#4-one-size-fits-all-32-byte-alignment A colleague points out that 32-byte alignment will hinder performance on some targets. At least on AArch64, the maximum alignment requirement for an A64 instruction is 16, so the stack alignment and parameter alignment is also set to 16. The assumed alignment from malloc is also 16. By making the type require 32-bytes this will force additional stack alignment, use of aligned alloc etc. It is possible that on some architectures with a load/store that only operates on 32-byte aligned types that this would be beneficial, but that should be defined by the ABI for that platform. https://github.com/llvm/llvm-project/pull/182733 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
