llvm dev - Jul 2016 - RFC: Strong GC References in LLVM

>
>
> 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
this
     // block along which the load may not be anticipated.  Hoisting the
load
     // 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>

> On Jul 15, 2016, at 5:24 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 
> 
> 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.
At some point I stopped thinking about this as a bug and realized that you just
need to think of LLVM as modeling speculative code barriers as memory
dependence. In LLVM, it makes no sense to have a readonly may-throw call.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/2ef60049/attachment.html>

Hi Andy,

Andrew Trick wrote:
 > At some point I stopped thinking about this as a bug and realized that
 > you just need to think of LLVM as modeling speculative code barriers as
 > memory dependence. In LLVM, it makes no sense to have a readonly
 > may-throw call.

The problem is that that model breaks down with aggressive aliasing
like:

void foo(int* restrict ptr) {
   *ptr = 40;
   may_throw(); // read/write call
   *ptr = 50;
}

Now it is tempting to CSE the store of 40 to *ptr.  If we can't do
that then what does restrict/noalias even mean?

-- Sanjoy

The call does not have to be read only, it just has to no alias the load
being pre'd.
The call may in fact be read/ write of some other memory

On Fri, Jul 15, 2016, 5:32 PM Andrew Trick <atrick at apple.com> wrote:
>
> On Jul 15, 2016, at 5:24 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
>> 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.
>
>
> At some point I stopped thinking about this as a bug and realized that you
> just need to think of LLVM as modeling speculative code barriers as memory
> dependence. In LLVM, it makes no sense to have a readonly may-throw call.
>
> Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160716/afd7640a/attachment.html>