[llvm-dev] Controlling parameter alignment (original) (raw)

Momchil Velikov via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 24 04:28:03 PDT 2021

• Previous message: [llvm-dev] Controlling parameter alignment
• Next message: [llvm-dev] Controlling parameter alignment
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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>

• Previous message: [llvm-dev] Controlling parameter alignment
• Next message: [llvm-dev] Controlling parameter alignment
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the llvm-dev mailing list