[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