Skip to content

[Integration][Go] Runtime LLVM support - #71

Open
zhouguangyuan0718 wants to merge 2 commits into
goallc:llvm23.1.masterfrom
zhouguangyuan0718:codex/runtime-compile-support
Open

[Integration][Go] Runtime LLVM support#71
zhouguangyuan0718 wants to merge 2 commits into
goallc:llvm23.1.masterfrom
zhouguangyuan0718:codex/runtime-compile-support

Conversation

@zhouguangyuan0718

@zhouguangyuan0718 zhouguangyuan0718 commented Aug 12, 2026

Copy link
Copy Markdown

Purpose

This PR is the integration and revision-bound payload anchor for dependent Go PR llvm#128. The implementation is split into three review layers in dependency order:

  1. [Go] Encode ABI0 in function symbol names #77 — centralized ABI0 symbol resolution (merged)
  2. [Go] Model runtime stack semantics and entry maps #73 — runtime stack semantics, function-level entry maps, and CFG-derived map-0 transitions
  3. X86: Repair Go ABI state at ABI0 boundaries #76 — X86 ABI0/ABIInternal boundary repair

#75 has been folded into #73 and closed. Please review functional diffs in #73 and #76. This PR intentionally keeps the combined head based on llvm23.1.master, because the payload publisher accepts only main-base PRs and dependent Go CI is pinned to this PR head.

Integrated behavior

  • ABI0 symbol identity is resolved centrally and preserved for late calls
  • go-nosplit is the sole target-level exception to stack growth and emits no morestack prologue
  • every GoObj Go function has one function-level entry ArgsPointerMaps record at map 0
  • runtime.morestack* is an ordinary ABI0 call, with no dedicated statepoint or GoObj name recognition
  • GoObj restores map 0 whenever the Machine-CFG-derived PCSP stream reaches entry stack depth; ordinary statepoints provide additional live maps
  • unused incoming pointers remain ABI-preserved for retry but are omitted from the entry GC bitmap
  • X86 repairs ABIInternal runtime register state across ABI0 calls and statepoint returns

Testing

Local validation of the rewritten stack:

The new head now needs revision-bound payload publication and dependent Go joint CI.

@github-actions

Copy link
Copy Markdown

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

Emit native Go stack checks by default for GoObj functions and use go-nosplit as the sole opt-out. Lower the morestack slow path as a raw ABI0 call rather than a statepoint.

Give every Go function an independent entry-argument STACKMAP. Serialize it as map zero, derive map-zero transitions from the CFG-aware PCSP stream, and retain ordinary statepoint maps at live callsites.

Preserve complete ABI register homes for stack-growth retries while omitting unused, potentially poison incoming pointers from the entry GC bitmap.
@zhouguangyuan0718
zhouguangyuan0718 force-pushed the codex/runtime-compile-support branch from c7d9623 to e544ba5 Compare August 13, 2026 12:50
zhouguangyuan0718 added a commit that referenced this pull request Aug 13, 2026
## 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant