GoObj: mark asynchronous-unsafe functions

[zhouguangyuan0718]

Summary

• recognize a go-async-unsafe LLVM function attribute during AsmPrinter emission
• carry that function-level state through MCContext into the GoObj writer
• emit canonical PCDATA_UnsafePoint=-2 for the entire attributed function; ordinary functions retain -1
• keep the implementation at the function boundary: no marker intrinsics, SelectionDAG pseudo-ops, shrink-wrap exceptions, or interval reconstruction

Rationale

The current functional write-barrier implementation must not be asynchronously preempted while its branchy critical sections are present. For now GoALLC marks every LLVM-emitted function unsafe for its whole body. This is deliberately conservative in scheduling, but it is semantically complete and does not inhibit LLVM memory optimization through marker side effects.

Exact unsafe intervals are deferred. The previous precise-range prototype is preserved at codex/go-unsafe-point-ranges-backup.

Relationship

This is split from LLVM PR #17 after LLVM PR #18 merged. It is independent of the AArch64 write-barrier opcode lowering in #17; Go PR #32 applies the attribute to every LLVM-emitted function.

Validation

• AArch64 lit verifies attributed -2 versus ordinary -1, including opt default<O2>
• focused LLVM lit: 2/2 with the write-barrier lowering test
• llc -verify-machineinstrs
• integrated plugin CTest: 47/47
• integrated cmd/internal/testdir Test/LLVM: 50/50 codegen and 46/46 runtime
• structured objview evidence confirms full-range -2 even for LLVM functions without write barriers
• git clang-format --diff and git diff --check

[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