[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