已开启
fix: keep llvm.cj.blackhole opaque through the optimizer to block LICM #604
fix: keep llvm.cj.blackhole opaque through the optimizer to block LICM #604
已开启
yanjs创建于 18 天前
yanjs
yanjs仓颉Developer
18 天前

llvm-project仓PR信息

变更内容**(必填)**

修复 blackBox-O2 下无法阻止 LICM 提升循环不变读取的问题(关联 issue 实测 11 个 micro-benchmark 读取类用例测量失效)。

  • CJRuntimeLowering.cpp:不再在 CJ 流水线最开头把 llvm.cj.blackhole 降级为带 ReadOnly 属性的 CJ_LLVM_BlackHole 函数调用。intrinsic 形态自带默认 may-read/may-write 内存效果,LICM 无法跨越,保持该形态即可让 blackhole 同时防 DSE 与 LICM;
  • CJRewriteStatepoint.cpp:新增 deleteBlackHoleIntrinsic(),在所有优化 pass 结束后将 intrinsic 零开销消除(有用结果 RAUW 为参数、无用调用删除、清理空声明);新/旧两套 pass manager 路径均覆盖(legacy 路径原先不调用 deleteUnusedBlackHole,一并补上,避免 intrinsic 泄漏进 codegen);
  • 测试:CJRewriteStatepoint/cj-blackhole.ll 增加 intrinsic 形态消除用例;新增 LICM/cj-blackhole-barrier.ll 正反对照(循环内有 blackhole 时不变 load 不得离开循环,无 blackhole 时会离开)。

变更类型**(必填)**

请描述本次Pull Request变更类型(原因),请在对应类型的括号内填写Y

  • 新增需求( )
  • 问题修复(Y)
  • 构建过程或辅助工具变动()
  • 文档更新()

变更内容自检

编译器及标准库编译通过截图证明(如涉及新增需求、问题修复、构建过程变动需提供)

本地 release 构建通过(git-sanity command -c build-cjc_r,build success),cjc / libLLVM-15.so / opt 均已重链。

端到端验证:对关联 issue 中的复现用例(@Bench 返回 arr[512],批内不变下标),cjc -O2 --test 编译后检查优化后 IR——blackhole 调用零残留,数组元素 load 位于被计时内层循环体内(修复前位于 preheader,每批只执行一次);benchmark 实测 1.71 ns(修复前失效模式约 0.4 ns,仅为框架空载开销)。

存量用例冒烟编译(string/BenchmarkStringBrackets.cjcollections_arraylist/BenchmarkArrayListBrackets.cj 等)无回归。

测试用例本地自验证通过截图证明(如涉及新增需求、问题修复需提供)

llvm-lit 三个目录结果:199 通过 / 6 unsupported / 1 失败:

  • Transforms/CJRewriteStatepoint(含扩展后的 cj-blackhole.ll):通过
  • Transforms/LICM(含新增 cj-blackhole-barrier.ll):通过
  • Transforms/CJRuntimeLowering:通过
  • 唯一失败 CJRewriteStatepoint/phi-select-cast.ll 为存量 stale 测试(期望 statepoint id i64 4,当前实现输出 i64 5):已用未含本修改的 pristine 构建复现同样失败,与本次修改无关。

其他信息

  • 语义变化:blackBox 由"仅值级屏障(防 DSE)"变为"同时防 LICM"。屏障是逐调用点的,仅影响显式使用 blackBox / @Bench 返回值的代码,不改变普通程序优化结果。
  • 落地后,此前因 LICM 失效的读取类 benchmark 数字会变大,这是测量对象恢复,不是性能回退。

关联的 issue

https://gitcode.com/Cangjie/llvm-project/issues/191

likedislike
CLA协议签署
当前Pull Request的提交暂无外部代码贡献者
合并受阻
yanjsyanjs仓颉Developer
18 天前 关联了issue:[Bug]: blackBox 在 -O2 下无法阻止 LICM 提升循环不变读取,导致基准测试测量失效
cangjie-ci成员
18 天前 评论:

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 信息
    • 回复 "start build cov":执行覆盖率构建工程,生成该提交的增量代码覆盖率报告

三、合入条件 ⚠️

  • 满足最低评审人数,且评审问题需全部解决;
  • 禁止合入本人创建的PR,需由其他协作者操作;
  • 合并前确保关联流水线任务运行成功(build-test-passed);
  • 需求类覆盖率门禁:当关联的 Issue 标题以 [feature]: 开头(需求类 Issue)时,联合提交中属于 cangjie_compilercangjie_runtimecangjie_stdxcangjie_toolsllvm-project 仓库的 PR,必须先回复 "start build cov" 触发增量覆盖率流水线并通过,使 PR 获得 cov-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.

五、补充说明 📢

likedislike
Ccangjie-ci维护者
18 天前 添加了label:1.3.0-alpha.03waiting-start-build
Ccangjie-ci维护者
18 天前 重置了测试状态