[PATCH] D14670: Fix bug 25440: GVN assertion after coercing loads

[Daniel Berlin via llvm-commits]

I think this is going to be pretty much impossible to solve sanely in the
current infrastructure.

Rather than try to make this more and more complicated, i would suggest we
just step back and go with a variant on your original patch.

The attached should work (untested though, not on a computer with actual up
to date llvm source ;P)
On Tue, Nov 17, 2015 at 6:00 PM, Weiming Zhao <weimingz at codeaurora.org>
wrote:

> weimingz updated this revision to Diff 40465.
> weimingz added a comment.
>
> (this patch is mainly for discussion)
>
> Hi Berlin,
>
> Very appreciate for the explanation.
> My previous order about NextNum was indeed wrong, and thus
> addToLeaderTable was never executed, which masked the another problem:
> the newly created inst (%0) will get the VN before %sub.ptr.rhs.cast25.
> The NextNum check won’t prevent this.
>
> Looks like we should only assign numbers for new instrs that would have
> been visited (we only do make ups). For new instrs inserted in future
> points, we just leave it and wait for it to be processed naturally.
> But I can't find such support from existing GVN framework. I have an
> approximated solution in the patch.
>
> Any suggestions?
>
>
> http://reviews.llvm.org/D14670
>
> Files:
>   lib/Transforms/Scalar/GVN.cpp
>   test/Transforms/GVN/pr25440.ll
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151117/00033d7c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GVNpatch.patch
Type: application/octet-stream
Size: 1436 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151117/00033d7c/attachment.obj>