[PATCH] D75903: [AArch64][CodeGen] Fixing stack alignment of HFA arguments on AArch64 PCS

[Lucas Prates via Phabricator via llvm-commits]

pratlucas added a comment.

>From the AAPCS64's Parameter Passing Rules section (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#642parameter-passing-rules), I believe the proposed handling is correct. The HFA related rules described in this section are:

  Stage B – Pre-padding and extension of arguments
  [...]
  B.2 	If the argument type is an HFA or an HVA, then the argument is used unmodified.
  [...]

  Stage C – Assignment of arguments to registers and stack
  [...]
  C.2 	If the argument is an HFA or an HVA and there are sufficient unallocated SIMD and Floating-point registers (NSRN + number of members <= 8), then the argument is allocated to SIMD and Floating-point Registers (with one register per member of the HFA or HVA). The NSRN is incremented by the number of registers used. The argument has now been allocated.
  C.3 	If the argument is an HFA or an HVA then the NSRN is set to 8 and the size of the argument is rounded up to the nearest multiple of 8 bytes.
  C.4 	If the argument is an HFA, an HVA, a Quad-precision Floating-point or Short Vector Type then the NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument’s type.
  [...]

As per rule `C.4`, the argument should be allocated on the stack address rounded to the larger of 8 and its Natural Alignment, which is 32 according to what is specified by the Composite Types rules in sectoin 5.6 of that same document (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#composite-types):

  5.6   Composite Types
  [...]
  - The natural alignment of a composite type is the maximum of each of the member alignments of the 'top-level' members of the composite type i.e. before any alignment adjustment of the entire composite is applied

In regards to the compatibility with other compilers, I'm not sure that following what seems to be an uncompliant behavior would be the best way to proceed. @rnk and @ostannard, what would be your take on this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75903/new/

https://reviews.llvm.org/D75903