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

[Daniel Berlin via llvm-dev]

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>