Cranelift: Patchpoint instruction?

[lachlansneff]

In order to support tiering jits efficiently, it may be useful to support a "patchpoint" instruction that is lowered to a call + some nops if the required space is larger than is needed for a call, but emits some data about its location in the compiled code so that it can be patched later on.

[sunfishcode]

It's not clear that LLVM-style "experimental.patchpoint" is a clean interface for tiering, and it's not clear that it's a good fit for Cranelift in general.

For security reasons and for performance on some platforms, it's desirable to avoid dynamically patching live code when we don't need to, so I'm kind of inclined to want Cranelift to steer users away from it, rather than providing features to facilitate it. A function pointer table approach would be simpler, avoid writable executable code, and would only add mild overhead to the lower tiers.

For implementing actual polymorphic inline caches and such, I expect we'll eventually want a mechanism that can support what WebAssembly may want to do, which will require designing something with a more specific, not to mention safe, interface.

[lachlansneff]

To implement OSR and similar features, we need to be able to reserve patchable areas of code. If a patchpoint or stackmap instruction isn't the ideal interface to do that, I'm happy to look into other approaches, but currently, cranelift provides no way to do that.

[sunfishcode]

The Cranelift plan had been that we won't OSR for the foreseeable future. So if you want to do it now, go ahead, but I'll just ask that you keep the patches as isolated as you can, to minimize the disruption for other users of Cranelift. In particular, I expect you'll need some significant changes in the register allocator, so be aware that we're expecting to do some major reorganization of that code.