llvm dev - Mar 2021 - Controlling parameter alignment

Just to be clear, the suggestion is to introduce `alignstack` to
affect argument alignment, while retaining
the current semantics for `align`?

Thus, a pointer argument having both `align(A)` and `alignstack(B)`
would itself be allocated at B boundary (if it happens to be passed in
memory),
while it would contain an A-aligned address?
> Using alignstack for byval would also eliminate the special rule (for
> align) there I guess.
So, `byval` arguments adopt the `stackalign` attribute with the same
semantics as the current `align`
and then `align` is invalid for `byval` arguments ?

Looks good to me.

-- 
Compiler scrub, Arm

On Wed, Mar 10, 2021 at 6:35 AM Momchil Velikov <momchil.velikov at
gmail.com>
wrote:
> Just to be clear, the suggestion is to introduce `alignstack` to
> affect argument alignment, while retaining
> the current semantics for `align`?
>
> Thus, a pointer argument having both `align(A)` and `alignstack(B)`
> would itself be allocated at B boundary (if it happens to be passed in
> memory),
> while it would contain an A-aligned address?
>
Yes, that's the proposal as I understand it.

> > Using alignstack for byval would also eliminate the special rule (for
> > align) there I guess.
>
> So, `byval` arguments adopt the `stackalign` attribute with the same
> semantics as the current `align`
> and then `align` is invalid for `byval` arguments ?
>
I think there is a backwards compatibility consideration here. It also
seems reasonable to allow `align` to appear with `byval` as an optimization
hint: the optimizer can assume the low bits of such a pointer are zero.

Looks good to me.
>
> --
> Compiler scrub, Arm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210310/b1e2ffc4/attachment.html>