MCP: New Tier-3 target for `x86_64h-apple-darwin`

[thomcc]

Proposal

Add support for the x86_64h-apple-darwin target to rustc. The x86_64h-apple-darwin target is the "enhanced for Haswell" version of x86_64-apple-darwin. The main reason to support this is for compiling code that can occupy the x86_64h entry of a universal binary (a "fat" mach-o file).

Details

For background: when a universal binary containing entries for both x86_64 and x86_64h is executed on a machine that supports x86_64h, then the program loader will execute the x86_64h code instead of the x86_64 code. Additionally, if a x86_64 machine without x86_64h support tries to load a MachO which only supports x86_64h, then a error is emitted at load time, which is preferable to the alternative where the load succeeds, but then later tries to execute an instruction unsupported on that machine, resulting in UB (likely a SIGILL).

IOW, this is useful for Rust projects that distribute precompiled binaries in at least two scenarios:

1. Projects that wish to distribute a universal binary that (possibly among others) contains entries for both x86_64 and x86_64h, thus allowing use of advanced CPU features (AVX2 and such) while avoiding the need for runtime target feature dispatch, or the need to to drop support for old machines.

2. Projects that wish to explicitly drop support for macOS on older intel chips from their compiled distributions, possibly because it's so very dependent on SIMD performance.

Comparison to x86-64-v3

You may notice that this target is somewhat similar to a hypothetical x86_64v3-apple-darwin target. This is true, however there are at least two differences:

1. Most obviously (but not most importantly): the set of target features this covers does not quite match those provided by -Ctarget-cpu=x86-64-v3

   The precise invocation would need to be more like -Ctarget-cpu=core-avx2 -Ctarget-features=-rdrnd,-aes,-pclmul,-rtm,-fsgsbase (or something along these lines), however this would be insufficient in practice, both due to the issues with disabling target features (generally requires a recompilation of the standard library), and more importantly, due to not providing the second benefit.

2. More critically, it bottoms out at the x86_64h-apple-macosx LLVM target, and thus the resulting mach-o may be used as the x86_64h entry in a universal binary.

   Note that inserting a binary compiled as x86_64-apple-darwin in the x86_64h slot is not possible (as the CPU subtype of that part of the MachO must be CPU_SUBTYPE_X86_64_H). I was not able to solve that by manually modifying the CPU_SUBTYPE in the MachO, but did not investigate why (possibly due to incorrect load commands), as doing this the "right way" was simpler.

Downsides

• This may be confusing to some users, for example, ones who fail to notice x86_64-apple-darwin and only see the x86_64h-apple-darwin target in things like --print target-list, or who think that they should compile all their code as x86_64h-apple-darwin. This is true, but seems acceptable and is a risk for any new target.

• There is some additional maintenance burden, although it may be handled identically to x86_64-apple-darwin in almost all cases, so that burden seems low. An initial implementation is available https://github.com/thomcc/rust/tree/x86_64h-target although I have not submitted it as a PR (yet) (Edit: PR is Add support for the x86_64h-apple-darwin target rust#108795).

• Infra costs if it ever moves to tier-2: While I think it's plausible that this eventually becomes a tier 2 target, this MCP is just about tier-3 support (as the target tier documentation states targets should start as tier3 before moving up), and "is it worth tier-2" is something I'd rather defend another day.

  Given the intended use case (universal binaries), I don't think there's much of a reason to ever support host tools — users should be able to use the x86_64-apple-darwin host tools just fine.

Mentors or Reviewers

No mentor is likely needed (already implemented), but I'm unsure who would be the best reviewer.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[wesleywiser]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted