rustc_const_eval: respect target.min_global_align

[folkertdev]

Currently different backends handle the target.min_global_align option inconsistently: llvm and gcc respect it, but miri/rustc_const_eval does not. I believe that rustc_codegen_cranelift can't yet support per-item alignment.

The only rust target that sets min_global_align today is s390x. In LLVM the only other target that also specifies a min_global_align is larai, which rust does not support. The nvptx targets inherit the min_global_align from their host.

Proposal

The min_global_align target option becomes a language guarantee: If the target specifies min_global_align (i.e. it is not None), all globals will have an alignment of at least the min_global_align specified by the target.

This allows unsafe code authors to write inline assembly and other code that relies on the alignment of globals.

Background

Issue #44411 describes a correctness problem on s390x, where a static is not sufficiently aligned: the larl instruction that LLVM generates assumes an even address, but e.g. a static containing a bool may have an odd address. Clang and gcc make sure that globals are always aligned properly, even if their type does not require it. A language guarantee is required to justify inline assembly using the same instruction.

See also #miri > alignment of globals on s390x

r? @RalfJung
@rustbot label +I-lang-nominated

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[saethlin]

"in practice" seems like unnecessarily wobbly language here. Can we say something more concrete, or if the answer is complicated point to where the full answer is?

[workingjubilee]

the actual answer is "LLVM and some other compilers generate incorrect code if globals have an alignment less than 2, as they generate accesses to globals using LALR, which requires alignment to even addresses in order to work".

[folkertdev]

Yeah, the situation here is a confusing

• technically, miri does not need to enforce this alignment of 2, because it does not actually emit the larl instruction that would behave incorrectly
• but in practice, both gcc, clang and rustc do respect this alignment
• intuitively miri should respect target.min_global_align
• the only way to observe its effect right now is to test the alignment of statics on s390x

Anyway I've updated the comment with why this test was written.

[RalfJung]

The way I'd frame it is that LLVM made the choice to access globals with an instruction that requires the address to be even (?!?), and we have to set some target option to ensure this is indeed the case. It is somewhat odd that LLVM doesn't ensure this by itself -- nobody asked it to use that instruction after all, that was its own choice, why do frontends even have to know about this? But that's a separate discussion from the one in this PR.

For this PR, the question is whether we promise to unsafe code authors that all globals on this target are going to be 2-aligned. If the answer is "no", then I don't think Miri should do anything here; the use of larl and the 2-aligning of globals is an implementation choice that we could take back any time. If we land this PR, we pretty much make a stable promise that all globals will be 2-aligned, and that should be documented somewhere.

Cc @rust-lang/opsem

[RalfJung]

Any chance this could be done with a macro rather than having to repeat the same code many times?

[folkertdev]

The target maintainer may have some background too, cc @uweigand.

[Darksonn]

For this PR, the question is whether we promise to unsafe code authors that all globals on this target are going to be 2-aligned.

There might be unsafe code authors that wish to use the larl instruction in their own inline assembly. That doesn't seem like an unreasonable expectation.

[RalfJung]

Yes, that would be the kind of argument requiring us to make this a language guarantee. Miri can't run inline asm, but arguably unsafe code authors could also cast a pointer to such memory to &u16 and justify it with the platform alignment.

But that requires making this alignment an actual language guarantee, so we should involve the lang team before landing this.

@folkertdev can you rephrase the PR description to make it clear that this is about elevating this target option to a language guarantee? Then we can nominate for t-lang discussion.

[folkertdev]

I updated the comment, hopefully that is sufficiently clear.

If this does become a language guarantee, I should write a test with a custom target that sets a much higher min_global_align, hence:

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[RalfJung]

Custom targets are unstable, and adding such a test at least in Miri will be somewhat tricky.

[RalfJung]

The nvptx targets inherit the min_global_align from their host.

That's a statement about LLVM or rustc? It seems like very undesirable behavior, so I hope it's not ours.^^ The generated code shouldn't depend on the host used for compilation...

[folkertdev]

The nvptx targets inherit the min_global_align from their host.

That's a statement about LLVM or rustc? It seems like entirely wild behavior, so I hope it's not ours.^^

That's about llvm, specifically the value is inherited here. spir is similar to nvptx, but it has no rust targets.

But now that I look a bit more carefully, also e.g. aarch64 windows has some custom alignment rules for globals here. That logic is based on

https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#alignment

That alignment logic is in the clang part of the code base, so presumably rustc would have to replicate it if it wants to be compatible.

The final case (similar to aarch64) is csky here.

[RalfJung]

That's about llvm, specifically the value is inherited here. spir is similar to nvptx, but it has no rust targets.

If Opts.HostTriple there is actually the host this runs on, then that is truly cursed. Cc @RDambrosio016 @kjetilkjeka

[uweigand]

The target maintainer may have some background too, cc @uweigand.

On our platform the ABI specifies that symbol values are guaranteed to be 2-byte aligned. All compilers for the platform will (by default) enforce that property for symbols they generate, and assume that property for external symbols they reference.

(As an extension, at least in GCC you can in fact override this and force generation of a symbol that is not 2-byte aligned; this requires an explicit attribute ((aligned (1))) and strictly speaking causes the program to no longer comply with the ABI - any user of that symbol will also have to use the aligned attribute to ensure correct code generation.)