[llvm-dev] RFC: Add guard intrinsics to LLVM
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 17 22:27:04 PST 2016
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
More information about the llvm-dev
mailing list