[Go] Lower stack ABI inputs with typed byval

[zhouguangyuan0718]

Summary

• encode Go frontend input allocation decisions in the IR carrier: direct values remain register inputs and non-empty memory-only inputs use typed, aligned byval pointers
• define AArch64 and X86 Go input rules in calling-convention TableGen and consume ordinary CCState assignments in formal-argument and call lowering
• reconstruct logical arguments once in the shared CodeGen GoISelLowering layer from OrigArgIndex, PartOffset, typed byval information, and CCValAssign results
• reuse each targets existing call and formal-argument value-lowering loops; the remaining target Go formal helper only initializes canonical homes, morestack register pieces, and GoObj entry pointer maps
• omit a stack fallback for direct inputs so frontend/backend register-budget drift fails closed instead of silently changing the Go ABI
• bind incoming byval parameters directly to mutable, aliased fixed Go argument homes
• retain ordinary LLVM byval copying as the sole correctness path for outgoing calls
• derive Go frame and argument metadata from the carrier-defined input layout; pointer-containing incoming byval homes remain fixed frame objects across statepoints, while pointers loaded from those homes use the generic spill path

Large memory results remain a separate goret follow-up. Go frontend integration is intentionally deferred until the LLVM-side follow-up PRs are complete.

Scope boundary

This PR contains no custom SelectionDAG store forwarding, no initializer or escape classifier, and no statepoint optimization for pointers loaded from byval homes.

Existing incoming argument-copy elision now applies only to direct register inputs. Go byval inputs are explicitly excluded and bind their already assigned incoming fixed home instead. Focused AArch64/X86 regressions show that a direct register input may reuse its fixed incoming home while ordinary byval lowering writes the outgoing stack slot, with no extra local stack object.

Pure-SSA aggregate source allocas and their outgoing copies are deliberately left for a separate LLVM optimization PR. Consequently the full LLVM-built runtime closure may temporarily grow frames enough to hit a nosplit limit, and compress/flate still reaches its existing SelectionDAG assertion. Those are not worked around here.

Validation

• exact PR head 9e2b25c: GoALLC LLVM CI linux-amd64 and linux-arm64 pass
• fresh Linux/amd64 LLVM Release-with-assertions dynamic payload and standard Go make.bash: pass
• Linux/amd64 Go-prefixed Generic/AArch64/X86 CodeGen tests: 64/64 pass
• Linux/amd64 full TestLLVM whitelist: pass in 474.423s; codegen graylist 0 pass / 52 allowed fail / 3 skip, runtime graylist 19 pass / 2 allowed fail / 5 skip
• Darwin/arm64 development payload and standard Go make.bash: pass; full TestLLVM retained the two known pre-refactor baseline issues in abi/many_int_input.go and the stale machine-args-pointer-maps MIR fixture, with no new failure
• focused ABI differential coverage across IR, MIR, GoObj argument/local maps, PCDATA, PCSP, link, stack growth, and execution: pass
• focused AArch64/X86 MIR checks prove the register input is stored to its incoming fixed home and to the outgoing byval slot with stack: []

No Go PR update is part of this revision.

[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