Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

The Miri subtree was changed

cc @rust-lang/miri

@rustbot labels +T-lang

If the idea with this is that passing -Cmin-function-alignment represents a language-level guarantee, e.g. that a naked function could validly rely on this minimum alignment holding when this flag is passed to prove the soundness of its operations -- that from a language spec standpoint, this is equivalent to marking each function with #[align(..)] -- then I'd suggest that a dual FCP with lang here is proper.

cc @rust-lang/lang

Yeah that sounds right. There is also a bunch of overlap with rfc 3806.

Specifically, it contains a section that attempts to define what alignment values are accepted. #[align] and -Cmin-function-alignment should accept/reject the same values.

@rust-lang/spec: What thoughts do we have about how to handle compiler flags that affect the language definition?

cc @RalfJung

Here's a question. Since this does have language-level effect, might this be better expressed as a crate-level attribute?

If there's a good reason, given the use case, for this to be a compiler flag instead, probably it'd be good to describe that in some detail.

If it can then be applied via --crate-attr similarly, then that should be fine for our use case.

Huh. That could be... interesting to work with, since it would logically apply only to entities that originate from that crate, right?

@folkertdev Do any of our tests verify that if you

• use this option on the functions described in a crate
• one is generic or from a trait or otherwise non-instantiated
• you instantiate that function in another crate without this flag

Then the resulting function is instantiated with the correct alignment? Where "correct" is... well, pick an answer, I guess?

☔ The latest upstream changes (presumably #142901) made this pull request unmergeable. Please resolve the merge conflicts.

@workingjubilee we don't, currently. I think the expected answer is clear though, because -Zmin-function-alignment is applied to all compiled crates, not just the top-level one?

I'm not sure how that would work with #![min_function_alignment = N], because then library crates could set the value as well? So far I've been thinking of this option as similar to -Ctarget-cpu or -Ctarget-feature: they are not properties of a crate but of the compilation as a whole.

What thoughts do we have about how to handle compiler flags that affect the language definition?

Is setting and then relying on the alignment fundamentally different from -Ctarget-feature=+avx2 and then asserting in the program that avx2 is available?

Is setting and then relying on the alignment fundamentally different from -Ctarget-feature=+avx2 and then asserting in the program that avx2 is available?

It's about whether we like this as a safety argument:

/// SAFETY: The pointee must be a 32-byte aligned function. It's OK
/// for the low-order bits of the function pointer itself to be
/// non-zero, e.g., if they're used for controlling the processor
/// mode.
unsafe fn f(x: fn()) { todo!() }
fn g() {
 let p = g as fn();
 // SAFETY: We compiled with `-Cmin-function-alignment=32`.
 unsafe { f(p) };
}

For avx2, I'd expect that the safety argument would be made by use of cfg(target_feature = ".."), if is_x86_feature_detected!("avx2") { .. }, etc., rather than by using the argument that it was compiled with -Ctarget-feature=+avx2 in the proof.

they are not properties of a crate but of the compilation as a whole.

Wait so, does this need to be handled like Target Modifiers?

Yes, unexpected, but here we are. There are a bunch of threads here, and I guess we don't have a great way of reaching consensus, so I'm trying to figure out what to do next.

Alignment bounds

I'm assuming the question of what to do with the alignment bounds will be handled by T-lang in RFC 3806. Currently it states that

The maximum alignment is the same as #[repr(align(...))]: 2²⁹. That
being said, some targets may not be able to support very high alignments in all
contexts. In such cases, the compiler must impose a lower limit for those
specific contexts on those specific targets. The compiler may choose to emit a
lint warning for high, non-portable alignment specifiers.

which I think in practice means

• for PE/COFF, 8192 is the hard limit
• for elf, 4096 is the soft limit, and we warn on anything higher while rust still supports kernel versions that use that upper bound (rust supports kernel version v3.2, the issue is fixed in v5.10, see Statics don't support alignments larger than the page size #70022 (comment) ) (we could error too, but there has been resistance to that in this thread; I'm also equating elf and linux, I'm assuming e.g. the BSDs behave like linux here, but have no way of verifying that)
• otherwise, we defer to the max LLVM value 2²⁹

Language guarantee

I believe that what RfL wants is a practical way to set the minimum alignment across the compilation. As far as I can tell now there is no need for a language guarantee on the alignment value (i.e. the alignment is not used in safety comments). That -Cmin-function-align is implemented as a #[align] on each function can remain an implementation detail, and we'll need to be careful to not claim that they are equivalent.

Target modifier

I've been trying to tease out what a target modifier is and what it is not. It looks like there is support for broadening the definition of a target modifier to something like

A target modifier is a flag where it is invalid if you link together two compilation units that disagree on the flag.

Where invalid includes, but is not limited to, the result being unsound.

Making -Cmin-function-align a target modifier sidesteps a bunch of questions around how crates interact, and practically speaking, both for the RfL tooling and performance, having the alignment value be consistent across the crate graph is probably the desired behavior anyway.

Unless someone speaks up about this I'll make the change in a couple of days.

Do we have precedent for such a "weak" target modifier? I know @Darksonn wanted to use target modifiers for some cases where it is not soundness-critical but otherwise still potentially bad to accidentally mix things, like sanitizer settings. However, I don't know if this alignment question falls into that scope.

Specifically, it contains a section that attempts to define what alignment values are accepted. #[align] and -Cmin-function-alignment should accept/reject the same values.

FWIW, as the author of that RFC, I think starting off with a blanket limit of 8192 for this flag is fine for an MVP of this flag. As others have said, it seems really unrealistic that a user would want to align all functions to a higher value. The limit should be changed to match the RFC once it is implemented, but that shouldn’t block stabilization of the flag.

Making -Cmin-function-align a target modifier sidesteps a bunch of questions around how crates interact, and practically speaking, both for the RfL tooling and performance, having the alignment value be consistent across the crate graph is probably the desired behavior anyway.

That and your plan on this sounds reasonable to me.

One note on this part though:

Language guarantee... I believe that what RfL wants is a practical way to set the minimum alignment across the compilation. As far as I can tell now there is no need for a language guarantee on the alignment value (i.e. the alignment is not used in safety comments).

While they're maybe not writing safety comments, I nonetheless read the original ask as for a guarantee:

Does rustc allow one to specify the alignment of a fuction starting address like -fmin-function-alignment or -falign-functions?

Asked because in Linux kernel, to enable dynamic function trace, on ARM64 the function addresses are required to be 8-byte aligned.

https://github.com/Rust-for-Linux/linux/blob/17a9992dd7e8388d13eab85d4099c0ddfc53b043/arch/arm64/kernel/ftrace.c#L95

At least, it's not obvious to me how ftrace could be used here soundly without such a guarantee.

I asked for some clarification at #t-compiler/help > ✔ Alignment for function addresses @ 💬, and the RfL developer confirmed that, as far as they are aware, no UB can result from misapplying the alignment:

if the function address is not aligned, function trace point will just ignore this function.

Hence, at the moment, I'm not aware of any concrete need for a language requirement. We can still make it one though, and at least I believe that we're keeping the door open to making it a language guarantee in the future.

if the function address is not aligned, function trace point will just ignore this function.

Ah, good to know, thanks for that.

We can still make it one though, and at least I believe that we're keeping the door open to making it a language guarantee in the future.

Yes, and making this a target modifier, as you're planning, probably makes this more palatable in any case.

Hm reading this again, I think we'll want to be careful/explicit in at least two aspects:

I believe that what RfL wants is a practical way to set the minimum alignment across the compilation. As far as I can tell now there is no need for a language guarantee on the alignment value (i.e. the alignment is not used in safety comments).

(The first point is already mentioned earlier, but summarizing again)

1. Clarify whether this flag is intended as a guarantee for a whole compilation graph, or merely a hint. In relation to this, can this flag be relied upon for (transitive) soundness requirements? I'm assuming that it cannot (AFAICT, we haven't fully determined this), in which case we should probably explicitly state that, because it forms part of the usage contract of this flag between the compiler and the user.
2. What stability guarantees do we have or not have for the "interface" of the flag and the behavior of the flag?
   • "Interface" stability guarantees: from a compiler stability perspective, if we hard error on say max alignment 8192 now, can we or can we not lower that upper bound if we find out new information (per target/platform or for other reasons) that indicate that we should've imposed a lower limit for $target/$platform?

We can still make it one though, and at least I believe that we're keeping the door open to making it a language guarantee in the future.

This might not necessarily be fully open. From a language perspective -- perhaps. But from an implementation (compiler/toolchain) perspective, this is not necessarily so. As mentioned above, precompiled standard library could potentially be of a different min alignment. So if we want to upgrade this to be a guaranteed min alignment across the whole compilation graph, that might be a spanner in the works.

I suppose in theory if -Zbuild-std becomes stabilized this might be less of an issue.

I also have another question: would -Cmin-function-alignment (whether hint form, or in some theoretical guarantee form) apply to extern functions? I guess why I'm asking is more for the "if this is intended to become a language guarantee", that can code also assume extern functions follow this min alignment?

(This is a less of a concern, but more of a question about what is the expectation on interactions.)

@rustbot concern interaction-with-extern-functions

Actually, let my try to use rustbot's concern functionality to make the existing discussions/concerns more explicit.

@rustbot concern per-target-vs-universal-max-alignment

Why should it be limited on all platforms? Can't we error when the alignment exceeds the maximum that the actual target we are compiling for supports? Maybe someone genuinely needs to align to 16k on ELF for whatever reason?

@rustbot concern hint-vs-language-guarantee-can-be-relied-upon-for-soundness

We should figure out if this is a hint or a language guarantee -- can this be relied upon for soundness?

@rustbot concern applicability-current-crate-or-whole-crate-graph

Looks like the current direction is "for the whole crate graph" (potentially "enforced" via Target Modifiers mechanism), but just noting a concern to make sure this is what we explicitly decide to go with.

@rustbot concern carve-out-interface-and-behavioral-stability-guarantees

See #142824 (comment)

I suppose in theory if -Zbuild-std becomes stabilized this might be less of an issue.

My understanding is that target modifiers effectively require -Zbuild-std. From the RFC:

https://github.com/rust-lang/rfcs/blob/master/text/3716-target-modifiers.md#guide-level-explanation

The requirement that all CUs agree includes stdlib crates (core, alloc, std), so using these flags usually requires that you compile your own standard library with -Zbuild-std or by directly invoking rustc. That said, some flags (e.g., -Cpanic) have mechanisms to avoid this requirement.

I also have another question: would -Cmin-function-alignment (whether hint form, or in some theoretical guarantee form) apply to extern functions? I guess why I'm asking is more for the "if this is intended to become a language guarantee", that can code also assume extern functions follow this min alignment?

You mean foreign functions here right (so, declared in an extern "abi" {} block)? Making that assumption would mean that linking to any foreign function that is not appropriately aligned would be UB.

Such a guarantee/requirement would be really restrictive, especially for the performance use-case. I guess RfL does control it's build process sufficiently to guarantee that external C code also follows the alignment, but in general that seems unlikely?

On the other hand, from the outside it's not really clear whether a symbol is a foreign function, or a vanilla rust function.

Yeah, I'm assuming that this flag wouldn't apply to extern functions as a hint or guarantee (I don't really see how it meaningfully can). Or rather, if for whatever reason the intended use case is a language guarantee, then in any case reasoning about min alignment of extern functions seems like "well, the burden of ensuring that said extern fns do have the min alignment falls upon the user, if the user wishes to rely upon that for soundness". I'm asking in case there are... interesting or really weird interactions.

@rustbot resolve interaction-with-extern-functions

(Ignore this, this is purely my skill issue)
@rustbot resolve resolve interaction-with-extern-functions

Well an implication is that you can't, for an arbitrary function pointer, assume that it is well-aligned, because it may be an extern function

the PR for making -Zmin-function-alignment a target modifier is up at #143323

As discovered in #143206 (comment), it looks like LLVM completely ignores function alignment specifications on WASM.

As discovered in #143206 (comment), it looks like LLVM completely ignores function alignment specifications on WASM.

That's tracked at #143368 now and yeah I assume it also affects this flag.

@rustbot concern wasm

@rustbot concern resolve-interaction-with-fn-ptrs

It seems like this does not actually interact with function pointers in any reasonable way, and in particular does not guarantee anything about the integral value of function pointers (see here).

That means this is entirely unobservable in the language itself, i.e. in pure Rust programs. It can only possibly be exploited by inline asm code that observes the layout of the generated machine code. We should make sure this is suitably documented as it is extremely surprising.

☔ The latest upstream changes (presumably #143556) made this pull request unmergeable. Please resolve the merge conflicts.

#144661 also relates to this -- const-eval prematurely considered function alignment as a property observable via function pointers, leading to nonsense behavior (arguably that could even be an unsoundness).