[PATCH] D9176: Add support for symbolic large constant entries inside stackmaps

[Marius Wachtler]

undingen added a comment.

In http://reviews.llvm.org/D9176#188933, @reames wrote:

> I say this specifically because I don't feel like I understand exactly what you're trying to propose.  Until that part is clear, I can't really offer anything in the way of useful review.


Sorry I overlooked your reply.
Maybe I can make clear what I have in mind by describing how I'm currently using this patch:

We (Pyston project) use patchpoints to implement inline caches and for deoptimization when using the LLVM tier.
For the deoptimization use case we add all variables to the patchpoint live args which we need too continue the execution in a lower generic tier (e.g. interpreter). A lot of our generated IR values were direct inttoptr casts because we often generate instances of our objects outside of LLVM. For example we may generate instances of a python objects when we setup the internal representation of a python function which we then share between the interpreter and LLVM tier. That's why we had a lot of inttoptr casts in our generated IR, there are also additional args like pointers to the AST nodes which we will need for deopt.

Deopimizations should happen only very rarely that means that we don't want to actually load all the constants we specified as live values inside the patchpoint into registers/stack slots. Currently LLVM will put all arguments which are constants inside the stackmap constant table in order to not have to generate code in front of the patchpoint to put all this constant values into register/stack slots. This is exactly how I would expect the behavior to be and how I need it.

But then I added a new feature: in order to speedup JITing time if we encounter the same function on the next application start I implemented an object cache for the LLVM generated code. This means I need to be able to relocate all this embedded pointers because the memory layout will not be the same. I choose to solve this by emitting special unique symbol name for all cases where I previously embedded the direct pointer value. This symbol names are deterministic, on the next startup when encountering the same function I can directly load it from the object cache and just have to return the real pointer values inside the RTDyldMemoryManager::getSymbolAddress() overloaded function.

The problem I encountered and this patch tries to solve is that LLVM will currently emit code which will load all this symbolic constants into registers before the patchpoint. With this patch we will stop emitting this machine instructions and instead emit constant table entries inside the stackmap.

Hope this helps understanding what I have done (even if my english isn't good), I successfully use this solution now since several weeks and it gave us a huge speedup.


Repository:
  rL LLVM

http://reviews.llvm.org/D9176