GoObj: preserve pcsp across disconnected emitted blocks

[zhouguangyuan0718]

Summary

Late target passes may remove the last CFG predecessor of a machine basic block while retaining that block in the physical emission order. The GoObj pcsp calculation previously required every emitted block to be reachable from the function entry CFG and failed even though the block still occupies a real PC interval.

This change:

• strictly propagates and validates pcsp through the entry-reachable CFG
• seeds each disconnected emitted component from the real SP state carried by physical emission
• continues to validate merges within each component
• restores an independently proven reachable-block entry state when dead layout reconnects to live code
• retains fail-closed behavior for SP overflow and inconsistent reachable/component-local merges

No Go frontend logic, package/function special case, or invented metadata is involved.

Validation

• new AArch64 and X86 MIR/GoObj tests cover real SP adjustments in disconnected emitted blocks and reconnection at a different depth
• existing reachable inconsistency tests remain fail-closed
• focused AArch64/X86 pcsp tests: 5/5 pass
• Darwin/arm64 LLVM O2 full go test errors passes
• GoObj inspection shows errors_test.TestJoinReturnsNil pcsp=176 across the former dead-layout interval and restoration to zero in the epilogue
• six PCLN/traceback cases pass on a validation layer containing the existing GoObj PCLN changes: issue73916, issue73916b, issue73917, issue73920, inline_caller, inline_callers

Two unrelated goobj-pcsp-cfg.ll expectation drifts reproduce on the unmodified v8 payload and are intentionally not included.

[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