LLVM fails to eliminate bounds checking for fixed-size arrays #9024
Comments
|
Interesting. If you remove the For some reason, it appears that the last I was testing this by passing the following code to llvm's (I added the |
|
This is still an issue despite the return value being tagged as |
|
This looks like a regression that happened somewhere between LLVM 3.2 and 3.3. I reduced the code to just a loop with the bounds check: ; ModuleID = '<stdin>'
define void @test() {
"function top level":
br label %loop
loop: ; preds = %body, %"function top level"
%0 = phi i64 [ 0, %"function top level" ], [ %2, %body ]
%1 = icmp ugt i64 %0, 2
br i1 %1, label %fail, label %body
fail: ; preds = %loop
tail call void @bounds_fail()
unreachable
body: ; preds = %loop
%2 = add i64 %0, 1
%3 = icmp slt i64 %2, 3
br i1 %3, label %loop, label %out
out: ; preds = %body
ret void
}
declare void @bounds_fail()and ; ModuleID = '<stdin>'
define void @test() {
body.2:
ret void
}but |
|
Filed a bug against LLVM at http://llvm.org/bugs/show_bug.cgi?id=18449 |
|
Looks like this is fixed. Using ; Function Attrs: uwtable
define void @_ZN6addf3220h7431f4d506cb9520daa4v0.0E([3 x float]* noalias nocapture sret, [3 x float]* noalias nocapture readonly, [3 x float]* noalias nocapture readonly) unnamed_addr #1 {
entry-block:
%s = alloca [3 x float], align 4
%3 = bitcast [3 x float]* %s to i8*
call void @llvm.memset.p0i8.i64(i8* %3, i8 0, i64 12, i32 4, i1 false)
br label %next7
next7: ; preds = %next7, %entry-block
%4 = phi i64 [ 0, %entry-block ], [ %5, %next7 ]
%5 = add i64 %4, 1
%6 = getelementptr inbounds [3 x float]* %2, i64 0, i64 %4
%7 = getelementptr inbounds [3 x float]* %1, i64 0, i64 %4
%8 = load float* %6, align 4
%9 = load float* %7, align 4
%10 = fadd float %8, %9
%11 = getelementptr inbounds [3 x float]* %s, i64 0, i64 %4
store float %10, float* %11, align 4
%12 = icmp slt i64 %5, 3
br i1 %12, label %next7, label %join9
join9: ; preds = %next7
%13 = bitcast [3 x float]* %0 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* %13, i8* %3, i64 12, i32 4, i1 false)
ret void
} |
unused_async: lint async methods
Now lints:
```rust
impl Foo {
async fn method(&self) -> &'static str {
"no await here"
}
}
```
changelog: [`unused_async`]: lint async methods
Fixes rust-lang#9024
Consider the following code:
This function results in the following LLVM assembly when compiled with --opt-level 3:
What's weird is that llvm opt (from LLVM 3.2) can optimize this just fine, maybe an optimization regression or we're lacking some optimization passes.
Also on an unrelated (?) note Mul can overflow:
The address computation overflows as well, yielding x[0] as a result.
The text was updated successfully, but these errors were encountered: