X86: Repair Go ABI state at ABI0 boundaries

[zhouguangyuan0718]

Summary

• keep R14 and XMM15 reserved under both Go calling conventions and retain the shared Go preserved-register model
• repair ABIInternal reserved state in a late X86 machine pass after register allocation, frame lowering, and scheduling
• identify direct ABI0 callees solely through the <ABI0> symbol suffix; statepoints use their existing calling-convention operand
• leave late special calls outside the ordinary ABI transition path: morestack resumes through gogo, and write-barrier thunks use their dedicated ABIInternal clobber contract
• keep SP-relative Go locals while preserving ABI-specific fixed incoming argument homes
• emit native-compatible symbol-free x86 TLS relocations for the R14 reload

Design

R14 and XMM15 are fixed reserved registers rather than ordinary caller-saved or callee-saved allocation resources. The transition repair therefore does not participate in SelectionDAG lowering and does not require a target pseudo or a distinct ABI0 register mask.

The x86-go-abi pre-emit pass scans finalized MachineInstr calls. For an ordinary Go call, <ABI0> is the only ABI0 identity. It inserts XORPS XMM15, XMM15 and a TLS reload of R14 before ABI0-to-ABIInternal calls or after ABIInternal-to-ABI0 calls.

Calls inserted late without the ordinary Go call mask are intentionally ignored. This matches native Go behavior for split-stack morestack calls and write-barrier thunks.

Stack position

This is the X86 ABI-boundary layer on top of merged #73 and merged #77.

#71 remains the temporary cross-repository integration and payload PR until this PR is merged.

Testing

• independent Release plus assertions build of llc and FileCheck
• focused LLVM lit validation: 7 of 7 passed
• verified normal calls, statepoints, stack-return statepoints, GoObj relocations, stack growth, PCSP CFG handling, and ABI symbol naming
• verified pass timing: no repair at finalize-isel or immediately before x86-go-abi; repair appears only after the late pass
• verified native-special behavior: no repair is inserted after morestack or write-barrier calls

[github-actions]

Hello @zhouguangyuan0718 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

• All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
• The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
• Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.

---

Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.

---

If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you,
The LLVM Community