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

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

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
>

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.
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?
>>
>> 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