llvm dev - Mar 2021 - Controlling parameter alignment

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>

From: Reid Kleckner <rnk at google.com>
> On Wed, Mar 10, 2021 at 6:35 AM Momchil Velikov <momchil.velikov at
gmail.com> wrote:
>> 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.
Updating the FE to emit `stackalign` for `byval` arguments  would cause quite a
bit of churn in the testsuite, but
the updates can be done automatically.

Then in the BE, `byval` arguments will use `stackalign`,  missing that, fall
back to uisng `align`  to affect
stack slot alignment.

~chill

On Wed, Mar 10, 2021 at 9:51 PM Reid Kleckner <rnk at google.com>
wrote:
>
> 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.
Something is not quite right here.

We have up to three relevant alignment properties for a parameter:
 * the alignment of the parameter itself (if it happenes to be passed in
memory)
 * if it's a pointer, the actual alignment of the pointed to memory (as an
optimisation aid)
 * if it's a `byval` or a `byref` argument, the minimum alignment of the
storage, allocated
   for the original argument value (ABI affecting).

For non-pointer arguments `alignstack(N)` gives stack slot alignment.
For pointer arguments, we retain that use of `alignstack(N)` and also have
`align(M)` to give
the actual alignment of the contained pointer.

Now when we add `byval` or `byref` to the above, there is no attribute left
to give the alignment
of the allocated memory. We thought of using `alignstack(N)`, but that
would leave us without a way
to specify the pointer alignment itself.

~chill

-- 
Compiler scrub, Arm
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210324/f8b50a43/attachment.html>