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

[Sanjoy Das via llvm-dev]

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