[llvm-dev] RFC: Add guard intrinsics to LLVM

[Sanjoy Das via llvm-dev]

So, to summarize, the action item here is (let me know if you
disagree): I need to go and fix the
semantics of deopt operand bundles around IPO, and once that is done,
the weirdness around guards being readonly only in their immediate
callers will no longer be an issue.

-- Sanjoy

On Wed, Feb 17, 2016 at 10:27 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
> Some minor additions to what I said earlier:
>
> On Wed, Feb 17, 2016 at 9:59 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
>> My interpretation here is that we're not modeling the deopt
>> continuations correctly.  Above, the XXX continuation is a delimited
>> continuation that terminates at the boundary of @bar, and seen from
>> its caller, the memory effect (and any other effect) of @bar has to
>> take into account that the "remainder" of @bar() after @foo has
>> returned is either what it can see in the IR, or the XXX continuation
>> (which it //could// analyze in theory, but in practice is unlikely
>> to).
>
> A related question is: down below, we're clearly allowed to forward 42
> into v0 after inlining through the call to @bar (while before inlining
> we weren't, as shown earlier) -- what changed?
>
> ```
> global *ptr
> declare @foo() readwrite
> def @bar() { call @foo() [ "deopt"(XXX) ]; *ptr = 42 }
> def @baz() { call @bar() [ "deopt"(YYY) ]; int v0 = *ptr }
>
> inlining ==>
>
> global *ptr
> declare @foo() readwrite
> def @bar() { call @foo() [ "deopt"(XXX) ]; *ptr = 42 }
> def @baz() { call @foo() [ "deopt"(YYY XXX) ]; *ptr = 42; int v0 = *ptr }
>
> ```
>
> What changed is that inlining composed the normal (non-deopt)
> continuation in @baz() with the non-deopt continuation in @bar (and
> the deopt continuation with the deopt continuation).  Thus the
> non-deopt continuation in @baz no longer sees a merge of the final
> states of the deopt and non-deopt continuations in @bar and can thus
> be less pessimistic.
>
>> This is kind of a bummer since what I said above directly contradicts
>> the "As long as the behavior of an operand bundle is describable
>> within these restrictions, LLVM does not need to have special
>> knowledge of the operand bundle to not miscompile programs containing
>> it." bit in the LangRef.  :(
>
> Now that I think about it, this isn't too bad.  This means "deopt"
> operand bundles will need some special handling in IPO passes, but
> they get that anyway in the inliner.
>
> -- Sanjoy



-- 
Sanjoy Das
http://playingwithpointers.com