Maksim Panchenko via llvm-dev
2015-Sep-08 18:56 UTC
[llvm-dev] 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 >
Maksim Panchenko via llvm-dev
2015-Sep-10 17:50 UTC
[llvm-dev] LLVM as a back end for HHVM
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