[PATCH] D16439: [PlaceSafepoints] Introduce a -spp-no-statepoints flag

[Sanjoy Das via llvm-commits]

sanjoy added a comment.

In http://reviews.llvm.org/D16439#333624, @reames wrote:

> Sanjoy, I don't see anything wrong with this patch per say, but I'm a bit confused about how you're expecting this to fit together with RS4GC.  That pass currently has two modes, one which consumes statepoints, and one which consumes calls with deopt.  You don't seem to be emitting either form here.  What am I missing?


That's a really good question.

For environments that don't care about deoptimization at all (which I
think includes LLILC), RS4GC can be run with
`-rs4gc-allow-statepoint-with-no-deopt-info`.  Then RS4GC will work as
expected with calls / invokes with no `"deopt"` operand bundles
(i.e. the deopt section in the gc.statepoints it creates will be empty
for such calls).

Environments that **do** care about deoptimization and want to run
PlaceSafepoints will have to provide their own deopt info, and attach
them to all non-leaf calls including the call in the safepoint poll
slow path, if there is one.  For sanity checking, in these cases we
should set `-rs4gc-allow-statepoint-with-no-deopt-info` to `false`
(unless not having deopt info for some gc.statepoint is actually a
valid thing to do in this case).

And the third possibility is to not use PlaceSafepoints at all, and
instead emit all safepoint polls early (with appropriate deopt state),
and have an optimization pass remove unnecessary polls as appropriate;
and run RS4GC afterwards.  For some strange reason, this third
approach sounds very familiar. :)

Are there other possibilities that you can think of?


http://reviews.llvm.org/D16439