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

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>

IE:

int *A;
int *D;

int bar()
{
  *D = 5;
if (im_bored)
 throw();
return *D;


}

void foo()
{
int z = 0;

if (?)
{
  z = *A + 5;
}
bar()
y = *A + 5;

}

or whatever.
bar will be noalias of *A, but still validly throws, and is even read-write.



On Fri, Jul 15, 2016 at 6:26 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 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/20160715/18e06525/attachment.html>

> On Jul 15, 2016, at 6:51 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> 
> IE:
> 
> int *A;
> int *D;
> 
> int bar()
> {
>   *D = 5; 
> if (im_bored)
>  throw();
> return *D;
> 
> 
> }
Not to argue this, since I completely agree philosophically. But my mental model
for LLVM is that the “throw()” itself writes unknown memory…

Incidentally, it seems arguable to me to turn “maythrow” calls into invokes. The
thing I don’t like about invokes is the shared landing pads.

What I was saying that started this tangent is that the notion of early exits
would be hard to get rid of entirely. I at least wanted a ‘noexit/terminate’
attribute, but I guess no one needed it badly enough yet to add it.

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