-
Notifications
You must be signed in to change notification settings - Fork 12.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WRONG code, likely JumpThreadingPass #79175
Comments
Here's a godbolt link seemingly showing the same thing: https://godbolt.org/z/dMPaP7161 . I can't replicate this at 6a7abea with just |
Ah -- because it's sensitive to the
Which I think is saying that the GEP is believed to not-alias the "f" variable, wheras it might alias depending on the value of %0. Stepping through other things during the alias query, I see (However this isn't my normal wheelhouse, so that might not be true!). |
That sounds about right to me. JumpThreading performs lazy DT updates, so it's not legal to use DT during the transform. BasicAA in principle already supports working without DT, but it may be a bit tricky to avoid the DT use just in JumpThreading, given how this is all wired up in the pass manager. |
Somewhat reduced test case: ; RUN: opt -S -passes=jump-threading < %s
@f = external global i32
define void @test(i64 %idx, i32 %val) {
entry:
%cmp = icmp slt i64 %idx, 1
br i1 %cmp, label %for.body, label %return
for.body:
%f = load i32, ptr @f, align 4
%cmp1 = icmp eq i32 %f, 0
br i1 %cmp1, label %cond.end, label %cond.false
cond.false:
br label %cond.end
cond.end:
%phi = phi i32 [ %val, %cond.false ], [ 1, %for.body ]
%cmp.i = icmp sgt i32 %phi, 0
%sel = select i1 %cmp.i, i32 0, i32 %phi
%f.idx = getelementptr inbounds i32, ptr @f, i64 %idx
store i32 %sel, ptr %f.idx, align 4
%f.reload = load i32, ptr @f, align 4
%cmp3 = icmp slt i32 %f.reload, 1
br i1 %cmp3, label %return, label %return
return:
ret void
} |
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
/pull-request #80274 |
Not merged yet. |
PR has been created, we will track the status there. |
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
(cherry picked from commit 7143b45)
…9294) JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm#79175. (cherry picked from commit 4f32f5d)
wrong0.tar.gz
(reduced c test case, should print 0)
runline:
clang -O3 -march=arch13 wrong0.i -o a.out -w -mllvm -available-load-scan-limit=12
The function n() below is called two times in the reduced test case. The first time f[0] has a value of 0 at the start of the function, and a value of 1 at the end. The second time n() is called, f[0] has a value of 1 at the top, while it is then set to 0 by k().
This is the transformation of jump threading:
Before (left),
@f
is reloaded for the final icmp in cond.end (%3), which is necessary as the store to %conv2 just above goes to the same address. However, to the right JumpThreading has changed the final icmp to use the %5 value, which does not reflect the stored value of %conv2. This seems wrong and maybe JT has missed the fact that %arrayidx aliases@f
?@jmorse @MatzeB @nikic
The text was updated successfully, but these errors were encountered: