[llvm-dev] LLVM as a back end for HHVM

[Philip Reames via llvm-dev]

On 09/08/2015 05:29 PM, Brett Simmers wrote:
> On 9/8/15 9:35 AM, Philip Reames wrote:
>> On the VM state synching side of things, I'm curious about the tradeoffs
>> involved in the approach you've used.  I'm guessing from what you said
>> that you're essentially pre-reserving a set of allocas for the spill
>> locations, somehow registering those with your runtime once, then
>> emitting stores down the unlikely path into those allocas.  Is that
>> roughly right?
>
> It's even simpler than that: the stores to spill VM state go directly 
> to the VM locations where those values belong. We only ever side-exit 
> at bytecode boundaries, so every live value has a place to live on the 
> eval stack or in a local variable (every PHP function has a fixed 
> number of local variables, and space for those is allocated on the 
> eval stack). This means that the side-exit path doesn't have to know 
> if the next bytecode is going to executed by the interpreter or by 
> more jitted code, since they'll both read values from the same locations.
Ah, gotcha.  I'd assumed your were intermixing your language and 
execution stacks.  Yeah, if you're maintaining them separately, 
transitioning becomes much easier.

Just as a sanity check, the compiled code does end up forwarding all the 
loads and keeping everything in registers within a single compilation 
right?  I'd assume you'd have to for decent performance, but your 
description almost makes it sound like it doesn't.

Philip