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

[Philip Reames via llvm-dev]

On 09/08/2015 11:56 AM, Maksim Panchenko wrote:
> On 9/8/15, 9:35 AM, "Philip Reames" <listmail at philipreames.com> wrote:
>
>>>> 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.
Just to be clear, you're talking about representing a call to a function 
at a constant address right?  With no additional constraints?  If so, 
introducing a function declaration and using the link/resolver 
functionality provided by MCJIT seems like a more natural fit.  The only 
real downside to that is that you end up with a generic far-call and we 
don't have a way to indicate a particular call is in fact near enough 
for a pc-relative offset.
>
> 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.
This actually sounds like both a useful debugging feature and a 
reasonable use of metadata.  Given there's no *correctness* requirement 
that the metadata be preserved, it seems like a reasonable fit.  If you 
wanted to propose this upstream, I could see this being really useful 
with some revision.  My biggest concern would be whether this overlaps 
with something we already have in the debug info support.
>
> Maksim
>