CodeGen: support plugin IR passes immediately before ISel

[zhouguangyuan0718]

Summary

• add TargetPassConfig::addPreISelPass so pass plugins can schedule legacy IR function passes after CodeGenPrepare and immediately before SelectionDAG
• preserve inlineasm_br indirect-target CFG successors when BranchFolding removes empty or branch-only blocks
• make Go alloca object-content liveness explicit and independent from a direct frame address carried only for relocation
• lower Go alloca, typed byval, and goret statepoint roots as frame-index rematerializations instead of ordinary spills
• add AArch64 and X86 regressions proving goret homes remain fixed-frame objects and are rematerialized after the statepoint

Motivation

GoALLC inserts statepoints after CodeGenPrepare, splits each statepoint continuation, and rebuilds fixed-frame memory addresses from the latest gc.relocate. A goret or byval home is a caller-owned stack object: its address must follow stack growth semantics, but it must not become an ordinary local-pointer spill. Separately, a direct frame base may be present in gc-live only to rematerialize that address, so GoObj needs an independent bit describing whether the objects pointer-containing contents are live at the callsite.

Validation

• focused AArch64 and X86 goret SelectionDAG regressions: 2/2 pass
• focused goret fixed-frame plugin IR, MIR, GoObj, and objview regressions: 4/4 pass
• dependent GoALLC plugin CTest: 102/102 pass
• dependent Go TestLLVM, with runtime kept native: pass
• archive/tar built and tested with -gcflags=all=-enablellvm -llvmironly and default<O2>: pass
• full dependent standard-library run currently exposes a separate O2 failure in encoding/json/jsontext; investigation continues in the Go PR

[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