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

Reid Kleckner via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 8 13:26:20 PST 2021


rnk added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1220
+``alignstack(<n>)``
+    This indicates the alignment that should be considered by the backend when
+    assigning this parameter to a stack slot during calling convention
----------------
chill wrote:
> rnk wrote:
> > This seems like you are introducing a new meaning to `alignstack`, which according to the comments, only affects function SP alignment, not parameter alignment.
> > 
> > I'm assuming the reason you can't use the regular `align` attribute is that it is overloaded to mean two things: the alignment of the pointer when applied to a pointer, and the alignment of the argument memory when that pointer argument is marked `byval`. If you want to resolve this ambiguity, it seems like something that should be discussed on llvm-dev with a wider audience.
> Sorry, I couldn't quite get it, do you suggest we should be using the `align` attribute instead of `alignstack`, if there  are no
> (major) objections on the llvm-dev list?
> 
> It certainly makes sense to me to use `align` as it already pertains to individual argument alignment (even though it's for pointers only now).
> 
Mostly I think I meant that this will be a big change in the meaning of either the `align` or the `alignstack` attributes, and that should be hashed out on llvm-dev.

Right now `align` is kind of a hybrid between an optimization annotation attribute, like `dereferenceable` or `nonnull`, and an ABI attribute, like `byval` or `inreg`. When `align` is used with `byval`, it affects argument memory layout. When `byval` is not present, it is just an optimizer hint. IMO, ideally, we should separate those two roles.

I should be able to control the alignment of the memory used to pass a pointer argument, at the same time that I annotate which low bits of the pointer are known to be zero.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75903



More information about the cfe-commits mailing list