Stabilize Arm64EC inline assembly

[taiki-e]

This stabilizes inline assembly for Arm64EC ("Emulation Compatible").

Corresponding reference PR: rust-lang/reference#1653

---

From the requirements of stabilization mentioned in #93335

Each architecture needs to be reviewed before stabilization:

• It must have clobber_abi.

Done in #131332.

• It must be possible to clobber every register that is normally clobbered by a function call.

This is possible from the time of the initial implementation.

• Generally review that the exposed register classes make sense.

The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable.

The following registers cannot be used in Arm64EC compared to AArch64:

• x13, x14, x23, x24, x28 (register class: reg)
• v[16-31] (register class: vreg)
• p[0-15], ffr (clobber-only register class preg)

These are disallowed by the ABI (see also abi docs for reg/vreg and #131332 (comment) for preg).

Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64.

---

cc @dpaoliello

r? @Amanieu

@rustbot label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp

[dpaoliello]

I'm fine with stabilizing this, but we should include a link to the Microsoft docs: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#authoring-arm64ec-in-assembly

At the very least, it should be noted that devs will need to call the appropriate thunks, and I don't believe there's any way to request that new thunks are generated.

[tgross35]

This will probably need lang input like #131258.

@rustbot label +I-lang-easy-decision

[Amanieu]

LGTM but needs lang FCP.

r? @joshtriplett

[joshtriplett]

LGTM.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[taiki-e]

@dpaoliello

I'm fine with stabilizing this, but we should include a link to the Microsoft docs: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#authoring-arm64ec-in-assembly

At the very least, it should be noted that devs will need to call the appropriate thunks, and I don't believe there's any way to request that new thunks are generated.

Thanks for the feedback. I added this to rules for inline assembly in the rust-lang/reference PR.

[workingjubilee]

At the very least, it should be noted that devs will need to call the appropriate thunks, and I don't believe there's any way to request that new thunks are generated.

@dpaoliello Will devs need to ask for new thunks to be generated, or are there existing thunks they can reach?

[traviscross]

@rustbot labels +I-lang-nominated

Hopefully easy decisions still need a nomination for them to come up on our agenda.

[dpaoliello]

@dpaoliello Will devs need to ask for new thunks to be generated, or are there existing thunks they can reach?

The thunks have different names and contents depending on the function signature (return and param types and calling conv). So if you are handwriting a function call to an x64 function, a function pointer, or an extern function that you don't know is ARM64EC then you need to call via a thunk with the appropriate name. If LLVM detects that some other code also needs that thunk then it will get generated, if not then you'll get a linker failure for an undefined symbol (the thunk you're calling).

If the dev needs a thunk generated, then they can use cc-rs to build a C file with MSVC that will request the thunk is generated: https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi#generating-entry-and-exit-thunks

So, again, not a blocker but devs must be aware that ARM64EC is ✨special✨ hence why I requested a link to the docs.

[traviscross]

@rfcbot reviewed

[tmandry]

@rfcbot reviewed

[nikomatsakis]

As before I am going to mark this as reviewed but I wish we had clearer lines of ownership

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

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

[bors]

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

[bors]

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

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[taiki-e]

(Rebased to resolve merge conflict with #131258)

[traviscross]

Given that it looks good to @Amanieu in particular, and has completed FCP...

@bors r=Amanieu,traviscross,joshtriplett

[bors]

📌 Commit 965a280 has been approved by Amanieu,traviscross

It is now in the queue for this repository.