smithp35 wrote: Looking at this from an AAPCS perspective [1], apologies I don't know this code well enough to evaluate the impact of the change.
> B.5 | If the argument type is a Composite Type then the size of the argument > is rounded up to the nearest multiple of 8 bytes > For each argument in the list the following rules are applied in turn until > the argument has been allocated. When an argument is assigned to a register > any unused bits in the register have unspecified value. When an argument is > assigned to a stack slot any unused padding bytes have unspecified value. As I understand it, the reason to extend the size of the argument is to maintain the 8-byte alignment of the stack, and when passing in registers, there's no register that contains more than one composite type. If the code here maintains the AAPCS rules then no objections from me. I'm not sufficiently familiar with code to check that, will need someone more familiar with clang to approve. There's no plans I'm aware of to remove the unused bits having an unspecified value, the callee can't trust that a malicious caller has followed the PCS, so must not assume anything about the value. [1] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#682parameter-passing-rules https://github.com/llvm/llvm-project/pull/215264 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
