[llvm] bc9a29b - Revert "Reapply D70800: Fix AArch64 AAPCS frame record chain"

[Owen Anderson via llvm-commits]

> On Sep 1, 2020, at 8:10 AM, Paul Walker via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
> Author: Paul Walker
> Date: 2020-09-01T16:09:37+01:00
> New Revision: bc9a29b9ee6ade4894252b1470977142c32b4602
> 
> URL: https://github.com/llvm/llvm-project/commit/bc9a29b9ee6ade4894252b1470977142c32b4602
> DIFF: https://github.com/llvm/llvm-project/commit/bc9a29b9ee6ade4894252b1470977142c32b4602.diff
> 
> LOG: Revert "Reapply D70800: Fix AArch64 AAPCS frame record chain"
> 
> This reverts commit e9d9a612084b47fc4277523561d61e675370c854.
> 
> This patch was previously revert by 04879086b44348cad600a0a1ccbe1f7776cc3cf9
> with the reapplication being done after breaking the assert used to
> ensure SP is always 16-byte aligned, which is a requirement of the AAPCS.
> 
> For extra context the latest patch caused runtime failures when
> building with "-march=armv8-a+sve -mllvm -aarch64-sve-vector-bits-min=256”.

Your claim here is incorrect, as discussed in the discussion Martin and I had before landing it.

The assertion is about how the stack pointer is computed, not how it is aligned.  The patch provides an example of a test case where it necessary in test/CodeGen/AArch64/framelayout-unaligned-fp.ll.  The *frame pointer* is unaligned in this testcase, which means that the stack pointer is then setup from it by subtracting a non-multiple of 16.

Unless you are prepared to debug the SVE failure soon, I believe this patch should be reapplied.  It is correct with respect to AAPCS, and as far as I can tell SVE support is insufficiently tested in public to require that all patches must not break arbitrary variants of it.

—Owen