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

[Sanjoy Das via llvm-dev]

Hi Eric,

(That's a very valid question, thanks for asking!)

The key difference between stackmaps and operand bundles it is more
natural to teach the optimizer to manipulate deopt operand bundles, as
opposed to values live in to a stackmap.  This becomes a requirement[0]
around inlining, since (say) we have:

```
void foo() {
  if (ptr == null) bail_to_interpreter(); [ "deopt"(i32 101) ]
}

void bar() {
  foo() [ "deopt"(i32 237) ]
}
```

and we wish to inline foo into bar.  Then the inlined body has to look like

```
void bar() {
  if (ptr == null)
    bail_to_interpreter() [ "deopt"(i32 237, i32 101) ]
}

// definition of foo() is elided
```

This is because if ptr is null, and we do have to bail to the
interpeter, we cannot just create one frame, but have to create *two*
interpreter frames, the younger of which is in state "i32 101"
(obviously a real deopt state will be more complex) and the older of
which is in state "i32 237".  Once these frames have been created,
execution will continue in the interpreter.

(Just to be very explicit about it -- the deopt state "i32 237", when
resumed to, will re-start interptered execution in the method @bar()
"as if" foo() had just returned.)

We want the inliner to do this kind of adjustment for us [1], and
doing this over an intrinsic is awkward.  For instance, an
intrinsified version of the above will look like:

```
void foo() {
  if (ptr == null) call @call_with_deopt_state(bail_to_interpreter, i32 101)
}

void bar() {
  call @call_with_deopt_state(foo, i32 237)
}
```

and the inliner and other IPO passes will have to have special
knowledge of the @call_with_deopt_state intrinsic.  Given how
different the semantics of @call_with_deopt_state are from a normal
call, it seemed more natural to make deoptimization state a first
class citizen of LLVM IR.

Secondly, the issues with deopt bundles and IPO this discussion
uncovered are also applicable to stackmaps; and since deopt bundles
are a distinct IR construct, phrasing the IPO / IPA restrictions will
be easier.

Does this answer your question?

[0]: This isn't a problem clients who don't do much optimization
within LLVM, but it is for us.

[1]: https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/Utils/InlineFunction.cpp#L1486

-- Sanjoy