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.

Sign up for GitHub

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

Specify guarantees for repr(rust) structs #1152

Merged
merged 7 commits into from
Sep 19, 2022
Merged

Specify guarantees for repr(rust) structs #1152

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5a8a664
Specify guarantees for repr(rust) structs
Darksonn Jan 31, 2022
e9a1ddf
Address review
Darksonn Feb 6, 2022
377c524
Fix typo
Darksonn Mar 22, 2022
f9ec1d2
Be less struct-centric
Darksonn May 9, 2022
1275bcc
Rephrase layout of tuples
Darksonn May 9, 2022
3ecc681
Remove stray 'minimum'
Darksonn May 9, 2022
1ae7c2d
Link to default representation.
ehuss Sep 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 21 additions & 3 deletions src/type-layout.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,9 +86,10 @@ String slices are a UTF-8 representation of characters that have the same layout

## Tuple Layout

Tuples do not have any guarantees about their layout.
Tuples have the same layout guarantees a struct with the same fields laid out
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
according to the default struct representation.

The exception to this is the unit tuple (`()`) which is guaranteed as a
The exception to this is the unit tuple (`()`), which is guaranteed as a
zero-sized type to have a size of 0 and an alignment of 1.
Comment on lines +91 to 92
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the former statement imply this statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not as I wrote it here, but you could certainly argue that it should be changed so it does.


## Trait Object Layout
Expand Down Expand Up @@ -162,7 +163,24 @@ representation will not change the layout of `Inner`.
Nominal types without a `repr` attribute have the default representation.
Informally, this representation is also called the `rust` representation.

There are no guarantees of data layout made by this representation.
There are very few data layout guarantees made by this representation. The only
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
guarantees are:

1. The fields of the struct are properly aligned.
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
2. The fields do not overlap.
3. The alignment of the struct is not less than the alignment of any of its
fields.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we guarantee that the alignment is equal to the largest alignment of the fields?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it ever becomes possible for PGO to change the layout of rust structs, it may be beneficial to increase alignment for certain types in some cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Can be ignored by author of PR)

Is it within the scope of the reference to include non-normative statements like:

"In practice, there's no reason a compiler would ever require a type to be more aligned than this, but we would like to reserve the right to do so, in case such a situation is found." (Possibly also noting that there isn't any clear reason why a user would need to care about this unless they were doing something that probably motivates using other repr annotations anyway, so it's basically just erring on the side of compiler freedom in a situation that doesn't much matter either way.).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would avoid saying anything about an upperbound on alignment for repr(Rust), especially if that statement isn't normative, because it might confuse what is guaranteed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we guarantee that the alignment is equal to the largest alignment of the fields?

I would say no. I'd like the freedom to be able to have struct Foo([u8; 16]); automatically get align(4), for example, if not everywhere at least on anything that doesn't like unaligned large reads.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, for that case, align(16) on x86_64, so you can use aligned SSE reads (movaps) to copy it.

Darksonn marked this conversation as resolved.
Show resolved Hide resolved

Formally, the first guarantee means that the offset of any field in the struct
is divisible by that field's alignment. The second guarantee means that the
fields can be ordered such that the offset plus the size of any field is less
than or equal to the offset of the next field in the ordering. The ordering does
not have to be the same as the order in which the field are specified in the
Darksonn marked this conversation as resolved.
Show resolved Hide resolved
declaration of the struct.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(also can be ignored)

If non-normative statements that provide motivation/context are permitted, it would also be worth noting here that only the compiler has enough information to optimally lay out a generic type for all possible type substitutions. i.e. repr(C) gets you consistency and control at the cost of sometimes not being able to always put generic fields in the best place.


Be aware that the second guarantee does not imply that the fields have distinct
addresses: zero-sized types may have the same address as other fields in the
same struct.

Darksonn marked this conversation as resolved.
Show resolved Hide resolved
### The `C` Representation

Expand Down