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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 15 18:26:40 PDT 2016


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>


More information about the llvm-dev mailing list