Stabilize -Cmin-function-alignment

[folkertdev]

tracking issue: #82232
split out from: #140261

Request for Stabilization

Summary

The -Cmin-function-alignment=<align> flag specifies the minimum alignment of functions for which code is generated.
The align value must be a power of 2, other values are rejected.

Note that -Zbuild-std (or similar) is required to apply this minimum alignment to standard library functions.
By default, these functions come precompiled and their alignments won't respect the min-function-alignment flag.

This flag is equivalent to:

• -fmin-function-alignment for GCC
• -falign-functions for Clang

The specified alignment is a minimum. A higher alignment can be specified for specific functions by annotating the function with a #[align(<align>)] attribute.
The attribute's value is ignored when it is lower than the value passed to min-function-alignment.

There are two additional edge cases for this flag:

• targets have a minimum alignment for functions (e.g. on x86_64 the lowest that LLVM generates is 16 bytes).
  A min-function-alignment value lower than the target's minimum has no effect.
• the maximum alignment supported by this flag is 8192. Trying to set a higher value results in an error.

Testing

• tests/codegen/min-function-alignment.rs tests the behavior of the -Zmin-function-alignment flag and how it interacts with #[align(N)].
• tests/ui/invalid-compile-flags/min-function-alignment.rs tests that incorrect alignments error

History

• add -Zmin-function-alignment #134030

The -Zmin-function-alignment flag was requested by rust-for-linux #128830. It will be used soon (see #t-compiler/help > ✔ Alignment for function addresses).

Miri supports function alignment since #140072. In const-eval there is no way to observe the address of a function pointer, so no special attention is needed there (see #t-compiler/const-eval > function address alignment).

Originally, the maximum allowed alignment was 1 << 29, because this is the highest value the LLVM API accepts. However, on COFF the highest supported alignment is only 8192 (see #142638). Practically speaking, that seems more than sufficient for all known use cases. So for simplicity, for now, we limit the alignment to 8192. The value can be increased on platforms that support it if the need arises.

---

r? @workingjubilee

the first commit can be split out if that is more convenient.

[rustbot]

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

[bjorn3]

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?

[folkertdev]

Well, so as we've discovered, alignment is just a mess between clang and llvm. For instance -falign-function only goes up to 1 << 16, although you can manually align a function to a much higher alignment.

For 8192, we know it'll work everywhere, and the logic for when to accept/reject an alignment value is clear.

This flag aligns all functions to the minimum, so I have a hard time seeing a realistic scenario where aligning all functions to 16k is a reasonable thing to do (the limit on individual functions will be handled separately).

[folkertdev]

So I think the options are:

1. Limit to 8192 on all platforms, it's consistent and unlikely to cause issues. The limit can be safely raised in the future if a need arises
2. Follow clang and allow 1 << 16, except when the target object format is COFF, then the limit is 8192.
3. Accept what llvm accepts: allow 1 << 29, except when the target object format is COFF, then the limit is 8192.

I've picked the most conservative one (again, with the option to relax the limits if the need ever arises), but if there is consensus now on one of the other options that's also fine.

[workingjubilee]

It is my understanding that on Linux kernels we still nominally support, overaligning beyond the page size, typically 4096, is not going to work properly, so it is arguable that even 8192 is too high.

[RalfJung]

(orthogonal to this PR)
it is not great that the logic for merging the per-fn alignment and the global alignment needs to be repeated in each backend.

Maybe codegen_fn_attrs should just take min_function_alignment into account?

[RalfJung]

In fact, using sess.opts in the interpreter is at best iffy since it means the interpreter can behave differently in different crates in the same crate graph which can cause unsoundness...

[traviscross]

@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

[folkertdev]

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.

[traviscross]

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

cc @RalfJung

[traviscross]

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.

[ojeda]

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

[workingjubilee]

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

[workingjubilee]

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