llvm dev - Sep 2015 - LLVM as a back end for HHVM

On 9/3/15, 3:34 PM, "Mehdi Amini" <mehdi.amini at
apple.com<mailto:mehdi.amini at apple.com>> wrote:

Hi,


On Sep 3, 2015, at 1:38 PM, Maksim Panchenko via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

Hi All,

Our team at Hip-Hop Virtual Machine (http://hhvm.com<http://hhvm.com/>)
have been experimenting with using LLVM as a code generator for x86-64. We have
been successfully running it for quite some time as a secondary back end. We had
to modify our version of LLVM and our mods were based on 3.5 release. At this
point we feel our requirements have become stable enough to start upstreaming
our diffs.

Great to read that you will upstream stuff!


A high-level overview of LLVM changes could be found at:

https://github.com/facebook/hhvm/tree/master/hphp/tools/llvm

The set of patches will be loosely based on the above,  as some of our
interfaces have changed since we’ve merged with the trunk.

All feedback is welcome. Please let me know if you are interested and I’ll CC
you explicitly on the reviews.


The patch is huge, I expect many small patches won’t be too much controversial,
but it would be nice to have some RFC-like document to discuss some high-level
design details.

That makes sense. I would think features like “location records” to be useful
outside of our project, and agree that it’ll require an RFC.

And I’ll be happy to be CC’ed on the reviews.
Sounds good!

Thanks,
Maksim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150903/e3c4cf1f/attachment.html>

Hi Maksim,

This looks really great, and I'm interested in helping review your
changes as they become ready.

Specifically on "Location records" --

Is it legal for the optimizer to drop the `!locrec` metadata that you
attach to instructions?  The general convention in LLVM is that
dropping metadata should not affect correctness, and if the location
record information is not best-effort or optional then metadata is
perhaps not the best way to represent it.

We're currently developing a scheme called "operand bundles" (more
details at [1], patches at [2]) that can be used to tag calls and
invokes with arbitrary values in a way that that they won't be dropped
by the optimizer.  The exact semantics of operand bundles are still
under discussion, and I'd like to make mechanism broadly useful,
including for things like location records.  So it'd be great if you
take a look to see if location records can be implemented using
operand bundles.  I was thinking of something like

  musttail call void @foo(i64 %val) [ "locrec"(i32 42) ]

where the "locrec"(i32 42) gets lowered to some suitable form in
SelectionDAG.

OTOH, if location records are optional and the optimizer dropping
location records is a quality of implementation issue, not a
correctness issue then what I said above is probably irrelevant.



I'm also curious about HHVM's notion of side exits -- how do you track
the abstract state to which you have to exit to?  Our primary use-case
for operand bundles is to track the abstract state of a thread (the
"interpreter state") that we need for side exits and asynchronous code
invalidation.

[1]: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089070.html
[2]: http://reviews.llvm.org/D12455 http://reviews.llvm.org/D12456
     http://reviews.llvm.org/D12457


-- Sanjoy

On 9/4/15 1:12 AM, Sanjoy Das via llvm-dev wrote:
> Specifically on "Location records" --
>
> Is it legal for the optimizer to drop the `!locrec` metadata that you
> attach to instructions?  The general convention in LLVM is that
> dropping metadata should not affect correctness, and if the location
> record information is not best-effort or optional then metadata is
> perhaps not the best way to represent it.
Unfortunately not - all of our uses of locrecs are required for correctness.
>
> We're currently developing a scheme called "operand bundles"
(more
> details at [1], patches at [2]) that can be used to tag calls and
> invokes with arbitrary values in a way that that they won't be dropped
> by the optimizer.  The exact semantics of operand bundles are still
> under discussion, and I'd like to make mechanism broadly useful,
> including for things like location records.  So it'd be great if you
> take a look to see if location records can be implemented using
> operand bundles.  I was thinking of something like
>
>    musttail call void @foo(i64 %val) [ "locrec"(i32 42) ]
>
> where the "locrec"(i32 42) gets lowered to some suitable form in
> SelectionDAG.
That sounds like it should work. One of the ideas behind locrecs was 
that they'd work with any instruction, not just call. We currently only 
use locrecs on call/invoke, and I can't think of anything we haven't yet
implemented that would benefit from locrecs on other instructions (that 
may change in the future, of course).
> I'm also curious about HHVM's notion of side exits -- how do you
track
> the abstract state to which you have to exit to?  Our primary use-case
> for operand bundles is to track the abstract state of a thread (the
> "interpreter state") that we need for side exits and asynchronous
code
> invalidation.
All VM state syncing for side exits is explicit in the IR we lower to 
LLVM (as a series of stores on an unlikely path), so we don't need 
anything special from LLVM here. We use locrecs to update our jump 
smashing stubs, so they know the address of the jump that entered the 
stub and should be smashed.

-Brett