Tracking issue for pref_align_of intrinsic

[RalfJung]

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.

[joshtriplett]

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]

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]

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:

• alignof and _Alignof return the minimum alignment for a type
• __alignof returns 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]

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)

Oh, that should not be relevant to us at all, huzzah.

[workingjubilee]

@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]

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