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

[Philip Reames via llvm-dev]

On 09/10/2015 10:50 AM, Maksim Panchenko wrote:
>
> On 9/10/15, 9:40 AM, "Philip Reames" <listmail at philipreames.com> wrote:
>
>> 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.
> With calls to fixed addresses we do exactly that and it works fine.
> I’m talking about a hypothetical case where the generation of the address
> happens in the code. In general the idea is to be able to locate code
> resulting
> from any instruction.
>
> BTW, is there a documentation regarding dropping metadata by optimizer?
> What are
> the exact rules? We are also using module flags metadata to alter
> alignment
> for code generation and we certainly don’t want that to be dropped.
I don't have a reference, but the general distinction is the following:
- Attributes effect correctness.  They must be preserved at all cost.  
They can limit optimizations, or even effect the ABI.
- Metadata provide optional hints.  It is *always* legal - though not 
desirable - for the optimizer to drop all metadata before doing anything 
else.   We try to preserve metadata, but failing to do so is at worst a 
performance problem, not a correctness issue. (*)

(*) Well, some of the module level metadata used by ObjectiveC breaks 
this rule, but if it's broken, no one has screamed yet.  If it ever does 
break, the response will likely be "don't use metadata".

> Perhaps there
> should be a way to distinguish metadata that can/cannot be arbitrarily
> removed?
> Oh wait, that’s the idea behind operand bundles :) They are mandatory
> metadata,
> right?
Essentially, yes.  :)
>>> 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.
> Cool. If this happens, location records will complement debug info.
>
> Maksim
>