[PATCH] D14670: Fix bug 25440: GVN assertion after coercing loads
Weiming Zhao via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 17 10:43:03 PST 2015
weimingz added a comment.
Hi Berlin,
Here is what’s happening:
When it sees the load in BB if.then.14:
%v1 = load i32, i32* bitcast (i8** @dfg_text to i32*), align 4
Then, it tries to do PRE.
So it finds the store in BB while.end:
store i8* %add.ptr, i8** @dfg_text, align 4
So, in GetStoreValueForLoad, it inserts a PtrToInt (line 1153)
Now, the BB becomes
while.end: ; preds = %while.cond.16
%add.ptr = getelementptr inbo %sub.ptr.rhs.cast25 unds i8, i8* %v2, i32 undef
store i8* %add.ptr, i8** @dfg_text, align 4
%sub.ptr.rhs.cast25 = ptrtoint i8* %add.ptr to i32 *** original ptrtoint ***
%sub.ptr.sub26 = sub i32 0, %sub.ptr.rhs.cast25
%0 = ptrtoint i8* %add.ptr to i32 *** newly created ***
switch i32 undef, label %sw.default [
This new instruction happens to have the same GVN as %sub.ptr.rhs.cast25
So, when GVN process BB while.end, if finds that %sub.ptr.rhs.cast25 already have a GVN, so deleted it and replaces the use with %0, which is wrong.
So it seems we do need to check if a VN exists before adding to LaderTable in addNewInstruction().
http://reviews.llvm.org/D14670
More information about the llvm-commits
mailing list