[Go] Model stack ABI values with preallocated and goret

[zhouguangyuan0718]

Summary

• represent non-empty Go ABI parameters assigned wholly to the stack with LLVM's standard typed preallocated(T) parameter attribute and operand bundle
• represent Go stack results with a typed goret(T) parameter attribute plus ordinary "goretindex"="N" key/value metadata; register results remain compact LLVM returns
• derive the memory-carrier masks from the Go frontend's ABI assignment so LLVM register classification cannot diverge from Go's allocation
• lower preallocated inputs directly into Go's reserved outgoing call frame on AArch64 and X86, without per-call dynamic stack adjustment or an intermediate argument alloca
• bind callees directly to incoming stack homes and retain the existing direct-home optimization only when the carrier is read-only and non-escaping; mutable or captured homes use an ordinary relocation spill
• preserve preallocated, goret, their operand bundles, and pointer fields through statepoint rewriting, Go pointer-map construction, and GoObj emission
• make llvm.call.preallocated.setup non-mergeable so optimization cannot combine tokens belonging to distinct Go call sites
• recover statepoint calls through target result-copy chains, including glued X86 REP_MOVS copies for multiple large stack results
• remove the remaining ABI0 nosplit fixture's legacy Go-specific byval carrier and exercise the reserved preallocated outgoing home instead

Go permits multiple mixed register/stack results, so this deliberately does not use LLVM sret. There is no function-level go_memory_results list: each memory result records its logical result index on its own carrier.

The standard preallocated IR contract is retained, but Go lowering uses the ABI's already-reserved outgoing call frame. The old fixed-home copy-elision hook explicitly excludes preallocated and goret carriers and remains only for direct register parameters.

Validation

• LLVM AArch64/X86 Go CodeGen, GoObj, statepoint, and preallocated optimization tests: 53/53 PASS
• focused touched-test suite including the large X86 goret/REP_MOVS statepoint regression: 24/24 PASS
• the regression crashes the unpatched llc with SIGSEGV and passes with two rep;movsq result copies after the fix
• the exact 6.8 MB Linux amd64 optimized reflect.Value.call IR now lowers successfully to a 1.6 MB object
• downstream GoALLC statepoint/GoObj/ObjView CTest suite: 77/77 PASS
• standard Go src/make.bash against the exact dynamic development payload: PASS
• downstream cmd/compile/internal/ssa with llvm23,dynamicllvm: PASS
• strict LLVM-built runtime dependency closure at default<O2>: PASS
• compress/flate current-package tests with native dependencies at default<O2>: 3 consecutive PASS
• standard-library LLVM CI driver: archive/zip, compress/flate, compress/gzip, and compress/zlib PASS with full LLVM dependency closures
• Linux amd64/arm64 qualification is running on this exact PR head

AI assistance was used to implement, analyze, and test this change. The resulting code and validation evidence were reviewed by the contributor.

[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]

I have read the LLVM AI Tool Use Policy and related contribution policies. The PR description now explicitly discloses the AI assistance used for implementation, analysis, and testing.