llvm - 使用 LLVM 编译时有什么方法可以避免删除重复的加载指令
问题描述
我正在创建 LLVM 前端模块通道。所以,基本上我需要复制所有加载指令并存储在不同的寄存器中。对于 clang、opt 和 llc 工具,在 -O0 处,删除了此重复的加载指令。我使用 objdump 查看了最终程序集,我可以看到删除了重复的加载指令。我想要一个不会删除重复加载指令的解决方案。
实际的 C 程序是,
int main(){
int* p = (int *)(0x600000);//Some address
int x=0x01, y=0x01;
int z;
z=x+y;
*p=z;
}
对应的 IR 是,
define i32 @main() #0 {
entry:
%p = alloca i32*, align 8
%x = alloca i32, align 4
%y = alloca i32, align 4
%z = alloca i32, align 4
store i32* inttoptr (i64 6291456 to i32*), i32** %p, align 8
store i32 1, i32* %x, align 4
store i32 1, i32* %y, align 4
%0 = load i32, i32* %x, align 4
%1 = load i32, i32* %y, align 4
%add = add nsw i32 %0, %1
store i32 %add, i32* %z, align 4
%2 = load i32, i32* %z, align 4
%3 = load i32*, i32** %p, align 8
store i32 %2, i32* %3, align 4
ret i32 0
}
但是当我的通行证被启用时,这个 IR 会改变,我只复制加载指令,加载地址是相同的内存,即使是重复加载也是如此。
更改后的 IR 将是,
define i32 @main() #0 {
entry:
%p = alloca i32*, align 8
%x = alloca i32, align 4
%y = alloca i32, align 4
%z = alloca i32, align 4
store i32* inttoptr (i64 6291456 to i32*), i32** %p, align 8
store i32 1, i32* %x, align 4
store i32 1, i32* %y, align 4
%0 = load i32, i32* %x, align 4
%1 = load i32, i32* %y, align 4
%2 = load i32, i32* %x, align 4 //Added
%3 = load i32, i32* %y, align 4 //Added
%add = add nsw i32 %0, %1
store i32 %add, i32* %z, align 4
%4 = load i32, i32* %z, align 4
%5 = load i32*, i32** %p, align 8
%6 = load i32, i32* %z, align 4 //Added
%7 = load i32*, i32** %p, align 8 //Added
store i32 %4, i32* %5, align 4
ret i32 0
}
我能够在 IR 级别看到更改的 IR,但在 llc 之后的最终组装级别看不到。我认为 llc 正在删除所有重复的负载。如何阻止 llc 删除?
注意:我尝试使所有变量都可变。为此,它可以工作,我可以在 llc 之后看到重复的负载。但是,这不是一个适当的解决方案。我不能让所有数千个变量都变得易变 :(。
解决方案
推荐阅读
- c# - 模拟接口方法的接口对象
- python - 在 SQLAlchemy 中使用 PostgresSQL INTERVAL,其中持续时间动态存储在 DB 中并且不是参数
- javascript - 如何在 Javascript 中格式化日期
- safari - 使用 WebRTC 或 RecordRTC 在 Safari 中录制视频
- spring - MongoDB Spring - 动态获取值
- hbase - 错误:单元格计数为 1,但在索引 0 处未返回单元格:行 = XXX
- python-3.x - 如何使用 ezdxf 编辑 AutoCAD 图层描述
- email - 通过任何中继的 SPF
- python - 熊猫数据框的条件合并
- python - 有没有办法使用 python imaplib 获取流中的大附件?