remove pref_align_of intrinsic

[RalfJung]

This intrinsic has never been stably exposed, and its existence occasionally causes confusion. Preferred alignment still exists as a concept inside the compiler that it might use e.g. for aligning globals, but there seems to be no good reason to expose it to clients. Also see this discussion on Zulip.

[rust-highfive]

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

[nbdd0121]

The Zulip thread does mention that this is used by c2rust though.

[RalfJung]

Good point, I pinged the person who wrote that on Zulip (not sure about their GH handle).

AFAIK we usually do remove features that have no path to stabilization. This one does not even have a tracking issue (to my knowledge) -- the least we should have if anyone actually needs this.

[RalfJung]

However, https://github.com/immunant/c2rust/search?q=pref_align_to turns up no results.

[tavianator]

https://github.com/immunant/c2rust/search?q=pref_align_of

[nagisa]

Hm, so it seems like the __alignof/__alignof__/_alignof/__builtin_alignof keyword in clang returns this preferred alignment rather than the ABI alignment, whereas the _Alignof and alignof keywordsreturn the ABI alignment. With that in mind, it does look lie c2rust's use of the intrinsic is well warranted.

[RalfJung]

https://github.com/immunant/c2rust/search?q=pref_align_of

oops

Hm, so it seems like the __alignof/alignof/_alignof/__builtin_alignof keyword in clang returns this preferred alignment rather than the ABI alignment, whereas the _Alignof and alignof keywordsreturn the ABI alignment. With that in mind, it does look lie c2rust's use of the intrinsic is well warranted.

By that argument, we should aim to have a function in mem that exposes this intrinsic, with an accompanying tracking issue. Using a perma-unstable feature (intrinsics) with no path towards stabilization is certainly not a solution.

[RalfJung]

Interesting, back in 2014, mem::align_of returned pref_align_of: https://github.com/rust-lang/rust/pull/14259/files#diff-6181b218ab2b0db797bea38c28defa9697bbb91d80a2b56b22c51015730e3ae6R79. This was changed in #25646. Ever since that PR in 2015, pref_align_of was inaccessible except via perma-unstable features.

[nagisa]

Ah yeah, I meant warranted in a sense that “this will produce the expected result” and less so a justification for use of an intrinsic as an implementation strategy. None of the mechanisms to obtain the preferred alignment in C are standard either, though, so c2rust could consider not supporting preferred alignment too.

[nbdd0121]

I assume there will be pre-C11 code that uses __alignof because there're not standard counterparts.

[RalfJung]

Since this concerns intrinsics, Cc @rust-lang/lang

[scottmcm]

With my lang hat on, I consider intrinsics entirely a compiler-team question so long as they're not otherwise exposed. So removing something unexposed sounds fine to me, FWIW.

(I have no opinion right now on whether it should be exposed.)

[RalfJung]

With my lang hat on, I consider intrinsics entirely a compiler-team question so long as they're not otherwise exposed.

Well, they are unstably 'exposed' and the main concern here is breaking c2rust which uses one of those intrinsics that are not really but de-facto sufficiently exposed.

[jackh726]

Even though I'm not really familiar with this intrinsic, my thoughts are: 1) What is/was its original purpose? 2) Is that purpose no longer needed or is it solved some other way? 3) If it isn't solved some other way, should it be? 4) How often is this actually used/how much breakage do we expect?

[jackh726]

@RalfJung what do you think the next step here is?

I don't feel comfortable approving this alone (at least not without the questions above answered, maybe also with lang FCP given this is unstably exposed).

[RalfJung]

Looks like some team needs to decide if we want to keep an unexposed un-RFCd no-tracking-issue intrinsic around because it has a downstream user. I don't think this is a good situation. If we didn't already have it, we certainly would not add it like that. Ideally, someone who needs that intrinsic would work towards exposing it, unstably at least.

[scottmcm]

It definitely doesn't need an FCP, since it's a reversible decision that doesn't affect stable.

I've nominated for lang to try to get unstuck.

[RalfJung]

Cc @thedataking for c2rust input.

[thedataking]

Appreciate the ping @RalfJung. The code which may emit this intrinsic was added to support LLVM 8 (commit).

The LLVM source code for getPreferredTypeAlign mentions that:

despite the name, the preferred alignment is ABI-impacting, and not an optimization.

Which sounds like we'd lose the ability to correctly transpile some code if preferred alignment is no longer exposed; we would have to emit an error if the input source uses this intrinsic.

cc @rinon @ahomescu

[tavianator]

Here are the relevant GCC bug reports about this:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 (C11 _Alignof)
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560 (C++ alignof)

I'm not sure exactly the sense in which the preferred alignment is ABI impacting. It will of course affect the ABI of things like char buffer[__alignof__(double)]. I thing GCC/clang will also align global/stack variables to the preferred alignment, and perhaps accesses to them will assume that alignment.

Emitting an error on __alignof__() seems too restrictive, there's lots of code using it. Maybe c2rust could compile it as if it were _Alignof() and raise a warning?

[joshtriplett]

We discussed this both in last week's and today's @rust-lang/lang meeting. In both cases, we came to the conclusion that we're not in a hurry to remove this intrinsic, and it's not obvious that the intrinsic couldn't be stabilized in the future if it makes sense to do so, given that people are using it.

Given that, we don't want to merge this PR at this time, and we don't mind letting this sit on nightly, unless there's some other reason that we should be considering this an urgent issue.

[RalfJung]

Okay, I opened a tracking issue at #91971 then.