Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AAPCS64] Clarify B.5 and B.6 #262

Open
rongcuid opened this issue May 15, 2024 · 1 comment
Open

[AAPCS64] Clarify B.5 and B.6 #262

rongcuid opened this issue May 15, 2024 · 1 comment

Comments

@rongcuid
Copy link

I would like some clarification of the rules B.5 and B.6 in AAPCS64.

Stage B is defined such that "for each argument in the list the first matching rule from the following list is applied. If no rule matches the argument is used unmodified". However, we see the rules:

  • B.5 covers if the argument type is a Composite Type
  • B.6 covers if the argument is an alignment adjusted type... however, it also mentions the possibility of such type being a composite type, and provides special case treatment for it.

Does B.5 already cover all composite types, making B.6's composite type rules redundant? Or are the rules meant to fall through in this case?

@smithp35
Copy link
Contributor

Thank you for pointing that out. We will need to think carefully about how to update the document. The Rule B.6 was added after B.5 specifically to deal with over or under aligned types, this does seem to clash with B.5 as worded today.

The intention behind the rules is:

  • The intent of B.5 is to ensure that objects on the stack have register-sized alignment.
  • The intent of B.6 is to avoid creating excess padding in stack arguments for overaligned types.

It is not clear to me that B.5 has much, if any effect given that C.14 "The NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument’s type." so even if a composite type had a size that was not a multiple of 8, then C.14 would ensure that the next parameter passed on the stack was at least 8-byte aligned.

Hope this helps.

The majority of overaligned types are caught by rule B.4 "If the argument type is a Composite Type that is larger than 16 bytes, then the argument is copied to memory allocated by the caller and the argument is replaced by a pointer to the copy." as the size of an aggregate is a multiple of the alignment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants