llvm-project仓PR信息

PR创建成功通知 | 感谢您的贡献 🎉

您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：

一、PR必须关联Issue ❗️

触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。

请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR

二、门禁触发规则 🔧

1. 门禁类型判定：由Issue关联的PR所属代码仓数量决定
   • 关联多个代码仓PR：触发「多仓联合门禁」
   • 关联单个代码仓PR：触发「单仓门禁」
2. 启动指令与检查范围：需主动回复指令：
   • 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
   • 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
   • 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
   • Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
   • commit 信息格式请遵循：Conventional Commits 规范
   • 请保证每一条 commit 都已添加 Signed-Off-By 信息

三、合入条件 ⚠️

• 满足最低评审人数，且评审问题需全部解决；
• 禁止合入本人创建的PR，需由其他协作者操作；
• 合并前确保关联流水线任务运行成功（build-test-passed）。

四、合并PR ✅

回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。

如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：

本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。

If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:

This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.

五、补充说明 📢

• 详细仓颉贡献流程：贡献流程(Cangjie Community Contribution)
• 门禁结果将自动评论至关联的所有PR，敬请留意。

⏳ 正在进行兼容性检测中，可能需要2~3分钟，请稍候，若10分钟无检测结果，请重新回复 start merge。

⏳ Compatibility check in progress. It may take 2–3 minutes. Please wait. If there is no result after 10 minutes, please reply with start merge again.

✅ 合入前兼容性检测通过。
涉及仓库：Cangjie/cangjie_compiler, Cangjie/cangjie_test, Cangjie/llvm-project

结论

• 分析过程：分析了 Cangjie/cangjie_compiler#1853 与 Cangjie/llvm-project#583。检查了编译器尾位置 sret 返回槽复用、LLVM STATEPOINT_TAIL_CALL 新伪指令、SelectionDAG statepoint 降低、GC 活跃性与 StackMap 派生信息去重，并核对了相关 LLVM 内部消费者。 Analyzed Cangjie/cangjie_compiler#1853 and Cangjie/llvm-project#583. Reviewed tail-position sret reuse, the LLVM STATEPOINT_TAIL_CALL pseudo-instruction, SelectionDAG statepoint lowering, GC liveness, StackMap derived-info deduplication, and the related LLVM internal consumers.
• 原因：兼容。PR #1853 仅在优化级别高于 O0 且确认调用方和被调用方 sret 参数类型一致、调用处位于尾位置时复用调用方返回槽；否则保留原有分配路径，未改变 Cangjie 源码公开声明或既有函数调用约定。PR #583 将 statepoint 尾调用限制在无返回值、无 GCRelocates 且调用序列栈调整为零的安全条件下，并让 AsmPrinter、栈指针插入、StackMaps 等 LLVM 内部消费者统一识别 STATEPOINT_TAIL_CALL；非安全场景回退到普通 STATEPOINT。新增的 StackMap 派生信息索引去重只压缩同一编码数据，不改变记录语义或外部接口。组合检查未发现旧源码、旧二进制、运行时栈图消费、构建入口或公开 SDK 契约需要迁移。 Compatible. PR #1853 reuses the caller sret slot only above O0, when caller/callee sret types match and the call is in tail position; otherwise it preserves the existing allocation path and does not change public Cangjie declarations or the established call convention. PR #583 enables statepoint tail calls only for void-returning calls with no GC relocations and zero call-sequence stack adjustments, while non-safe cases fall back to ordinary STATEPOINT. LLVM internal consumers consistently recognize STATEPOINT_TAIL_CALL, and StackMap derived-info deduplication preserves encoding semantics. No migration requirement was found for existing source, binaries, runtime stack-map consumption, build entry points, or public SDK contracts.
• 结论：兼容

✅ 以下PR将同时合入：

• Cangjie/cangjie_compiler#1853: fix: tail-position sret reuse for tail calls
• Cangjie/cangjie_test#1811: fix: add tail-call opt tests
• Cangjie/llvm-project#583: fix: tail call opt, stackmap opt

✅ The following PRs will be merged simultaneously:

• Cangjie/cangjie_compiler#1853: fix: tail-position sret reuse for tail calls
• Cangjie/cangjie_test#1811: fix: add tail-call opt tests
• Cangjie/llvm-project#583: fix: tail call opt, stackmap opt