[PATCH] GVN: Don't crash on an unreachable predecessor

[Rafael Espíndola]

Unfortunately it would still crash on the original testcase :-(

It now reduces to

define i32 @f(i32 **%f) {
bb0:
  %bar = load i32** %f
  br label %bb2
bb1:
  %zed = load i32** %f
  br i1 false, label %bb2, label %bb1
bb2:
  %foo = phi i32* [ null, %bb0 ], [ %zed, %bb1 ]
  %storemerge = load i32* %foo, align 4
  ret i32 %storemerge
}

So the assert fails since bb1 has a predecessor: itself.

That can be avoided with the attached patch (which would still need
the stronger test added). It fixes the original test is the bug report
and the clang-interpreter link where I first hit the crash.

I am currently testing a full bootstrap.


On 28 November 2014 at 20:24, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
> Don't crash when a PHI node comes from an unreachable predecessor.
> Fixes (?) PR21625 [1].
>
> I'm not really a memdep expert, so I'm not sure whether this counts
> as a fix or if this just papers over a problem that will show up
> some other way.
>
> In the attached testcase, bb1 hits `PredTranslationFailure` twice,
> causing the old assertion to fire.  My proposed fix is to weaken
> the assertion when the basic block has no predecessors:
>
> -      assert(I->getResult().isNonLocal() &&
> +      assert((I->getResult().isNonLocal() ||
> +              (I->getResult().isUnknown() && pred_begin(BB) == pred_end(BB))) &&
>
> This approximates the logic for the entry block, which skips this
> logic entirely with an early return:
>
>     // If this is the magic first block, return this as a clobber of the whole
>     // incoming value.  Since we can't phi translate to one of the predecessors,
>     // we have to bail out.
>     if (SkipFirstBlock)
>       return true;
>
> Thoughts?
>
> [1]: http://llvm.org/bugs/show_bug.cgi?id=21625
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 1381 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141129/69baec00/attachment.bin>