Repository navigation
Tracking issue for pref_align_of intrinsic #91971
Description
This intrinsic returns the "preferred" alignment of a type, which can be different from the minimal alignment exposed via mem::align_of. It is not currently exposed through any wrapper method, but can still be accessed by unstable code using the intrinsics or core_intrinsics features.
See #90877 for why it cannot be removed; the short summary is some code is actually using it. So let's have a place to centralize discussion about the intrinsics. (This is not a regular tracking issue because there is no associated feature gate, but close enough I think.)
It would be good to figure out what the "preferred alignment" actually is used for, e.g. there doesn't seem to be consensus on the question whether it is ever relevant for ABI or UB, or whether it is merely a hint used by the compiler to align some globals more than it has to.
Activity
joshtriplett commentedon Jul 27, 2022
Context for labels applied: it sounds like we need a summary of what precisely this means, as distinct from
align_of, in a way that isn't tied to the LLVM backend.workingjubilee commentedon Oct 31, 2024
cc @daltenty @gilamn5tr @mustartt I noticed that the latest change to the notion of "preferred alignment" in clang was for AIX: llvm/llvm-project@05ad8e9
I found the differential revision's commentary difficult to follow: https://reviews.llvm.org/D79719
But I do have a strong sense now that "preferred alignment" is a misnomer, here.
I have been doing a lot of work on the layout handling in our backend lately and I feel I should probably have at least a partial understanding of this, as it may impact the layout algorithm used for
repr(C)on AIX. Do you happen to know if there is public documentation that describes the "power rule" used here?daltenty commentedon Nov 1, 2024
Thanks for taking a look into this. We have actually also been taking an interest in the layout algorithm of
repr(C)on AIX and related topics, so this is timely. I'll share a bit of our understanding of theses topics from working on clang on AIX.(Borrowing from https://reviews.llvm.org/D54814's explanation) clang and gcc provide queries which may return two different alignment values for a type:
alignofand_Alignofreturn the minimum alignment for a type__alignofreturns the "preferred alignment"There's no hard and fast definition of "preferred alignment" but conventionally it is the ideal we'd like to provide for the type if we have the freedom to do so when allocating it (which may be different from the minimum alignment, guaranteed by the platform ABI, that any access can assume to be true).
Our understanding is that "preferred alignment" would be non-ABI affecting for C, however for C++ there is one known exception (referred to in https://reviews.llvm.org/D79719) where the preferred alignment is used in the ABI for 32-bit C++ on AIX for calculating the operator new cookie placement. (Not sure how relevant that is for Rust, but here for completeness)
Coming back to the "Power Alignment" rules, these rules are the default layout and alignment rules used by the C ABI on AIX (and historically some other Power platforms). A general description of this is given in the IBM XL compiler manual (https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes), though it is light on details when it comes to nested aggregates and other interesting cases. In general, there are special cases for first member doubles and similar types which need to be observed (recursively in some cases) to obtain a C ABI compatible layout.
workingjubilee commentedon Nov 1, 2024
Oh, that should not be relevant to us at all, huzzah.
workingjubilee commentedon Nov 1, 2024
@daltenty Currently our layout algorithms blithely assume that layout is architecture-specific, but while architecture is the strongest voice, it isn't the only one. To conform to the ABI described would require an AIX-specific layout algorithm.
daltenty commentedon Nov 1, 2024
Yeah, that is definitely a requirement for true C interoperability. Both the architecture and the platform's layout rules must be accounted for. The current design of
repr(C)seems to have issues with that.There's a fairly lengthy thread here debating about how to handle that: https://internals.rust-lang.org/t/repr-c-aix-struct-alignment/21594/36
workingjubilee commentedon May 31, 2025
After much discussion we have discovered that AIX's "weird" layout rules are actually a mistake in terms of the spec for the target and not a concern in the slightest.
Remove rustc's notion of "preferred" alignment AKA `__alignof`
Rollup merge of rust-lang#141803 - workingjubilee:remove-pref-align, …
Rollup merge of rust-lang#141803 - workingjubilee:remove-pref-align, …
Unrolled build for #141803
RalfJung commentedon Jun 12, 2025
#141803 removed this intrinsic, so the issue can be closed.
Rollup merge of #141803 - workingjubilee:remove-pref-align, r=bjorn3
Rollup merge of #141803 - workingjubilee:remove-pref-align, r=bjorn3
intrinsics: Add sorry implementation for pref_align_of
intrinsics: Add sorry implementation for pref_align_of
intrinsics: Add sorry implementation for pref_align_of
intrinsics: Add sorry implementation for pref_align_of
intrinsics: Add sorry implementation for pref_align_of
intrinsics: Add sorry implementation for pref_align_of
gccrs: intrinsics: Add sorry implementation for pref_align_of
gccrs: intrinsics: Add sorry implementation for pref_align_of