[llvm-dev] RFC: Strong GC References in LLVM

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 15 17:24:32 PDT 2016

> LLVM's design decision is one where everything has to explicitly care
> about implicit early exits to get correct answers (and not to harp too
> much, but "not everything does", years later).  If they don't, they will
> get wrong answers.
So, ironically, while looking at this, i noticed it turns out LLVM's PRE in
GVN is another place that does not do this correctly either.

It will insert and hoist loads past may-throw calls depending on whether it
thinks the call aliases the pointer or not (IE depending on what memdep
tells it, and memdep only cares about aliasing here when coming up with
deps), regardless of whether the call is nounwind or not.  This is rare but
can happen.

This is because memdep does this:
       // If the call has no effect on the queried pointer, just ignore it.
So it does not give a dep, and PRE then never does anything else to check
whether there is a may-throw call in the way of the hoist.

Testcase and patch coming.

Even more ironically, in gcc land, the non-local case would have been
prevented by this code GVN tries to use:

     // If any of these blocks has more than one successor (i.e. if the
edge we
     // just traversed was critical), then there are other paths through
     // block along which the load may not be anticipated.  Hoisting the
     // above this block would be adding the load to execution paths along
     // which it was not previously executed.
     if (TmpBB->getTerminator()->getNumSuccessors() != 1)
       return false;

Since it would have had edges to the exit block in any predecessor with a
may-throw call, it would have gotten the right answer.

Anyway, since i still don't plan on proposing changes here, i'm going to
stop harping on this for a while.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/e8cca797/attachment.html>

More information about the llvm-dev mailing list