[GoObj][X86] Include the return address in ABI0 entry pointer slots

[zhouguangyuan0718]

Summary

• keep GoABI0 fixed argument homes at logical Go argument-area offsets
• record synthetic morestack statepoint pointer locations relative to the physical entry RSP
• include the X86 return-address word for both GoABI0 and ABIInternal
• add a GoABI0 three-pointer MIR regression covering homes, loads, calling convention, and statepoint offsets

Root cause

For GoABI0, formal lowering recorded pointer word zero as RSP+0. X86 entry RSP points at the return address, while the first argument is physically at RSP+8. The GoObj writer correctly starts entry arguments at one pointer-sized word and rejected the producer location fail-closed.

The change separates the logical fixed-home offset from the physical stack-map offset. It does not change the ABI0 frame layout or relax GoObj validation.

Validation

• based on llvm23.1.master revision 588ad2f
• Release build with assertions and X86+AArch64 targets
• focused LLVM lit: 1/1 passed
• real internal/runtime/maps optimized IR: runtime.mapaccess2 ABI0 statepoint changed from offsets 0/8/16 to 8/16/24 and emitted GoObj successfully
• fresh Go toolchain build passed
• Go statepoint plugin CTest: 67/67 passed
• internal/runtime/maps O2 package tests: initial pass plus 3/3 repeat passes
• math/big production O2 build passed; its test-only rounding libcall failure is independent

[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

[zhouguangyuan0718]

Companion final-object/objview coverage is in goallc/go#123 (draft until this change is released). The current pinned payload reproduces the same fail-closed writer error on both Linux amd64 and arm64; the patched X86+AArch64 payload passes the full 67-test plugin suite.