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

[Maksim Panchenko via llvm-dev]

On 9/8/15, 9:35 AM, "Philip Reames" <listmail at philipreames.com> wrote:

>On 09/04/2015 11:36 AM, Brett Simmers via llvm-dev wrote:
>> 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.
>This will need to be a function attribute or operand bundle when
>upstreamed then, but that's a pretty simple change to make.
I think switching from metadata to operand bundles wouldn't be a problem,
assuming ³locrec² operand will have no effect on optimizations and codegen.
>>
>>>
>>> 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).
>Interesting.  What type of use cases are you imagining for locrecs on
>non-call instructions?  Are you thinking of things like implicit null
>and div-by-zero checks?  (The former is already supported in LLVM
>today.)  Or something else entirely?
One possible scenario is locating a constant address generation, e.g. for
an
indirect call destination. It¹s rather hypothetical example,
as we don¹t use it in this way at the moment. Substituting such address
isn¹t quite straightforward as the value could be scattered across several
instructions on some architectures, or be placed in a data section.

In general, we found locrecs useful for annotating IR and exploring
resulting
assembly. You could mark instruction in the IR, and the assembly dump will
include annotations showing all machine instructions generated from it.
However, this particular feature is orthogonal to our JIT requirements
and could go in separately if there¹s enough interest.

Maksim