[PATCH] New GlobalMappingLayer for Orc

Lang Hames via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 27 15:25:09 PDT 2015


Hi Andy,

I've added a global mapping layer in r246226. It only has the cut-down
interface I described earlier. When you build your own JIT stack you write
a convenience method along these lines:

class MyJIT {
  // Lower orc layers.
  GlobalMappingLayer<...> MappingLayer;
  // Any higher orc layers.

  addGlobalMapping(const GlobalValue *GV, void *Addr) {
    MappingLayer.setGlobalMapping(mangle(GV),
                                  static_cast<TargetAddress>(
                                    reinterpret_cast<uintptr_t>(Addr)));
  }

};

Cheers,
Lang.


On Wed, Aug 26, 2015 at 7:15 PM, Andy Somogyi <andy.somogyi at gmail.com>
wrote:

> Lang, if you want, go ahead and make any changes you see fit, I’m
> extremely swamped at the moment (I’m teaching 200 students in my intro to
> comp sci class, and its the start of the semester :) )
>
> The things I do need though is that we’re developing a JIT compiled
> language that make extensive use of name mangling, so thats why its
> important to have the
>
> addGlobalMapping(const GlobalValue *GV, void *Addr)
>
> functions, in that the name mangler can use the GlobalValue definition to
> generate a correct name for the given user pointer. Also, it nice convince
> to have the addGlobalMapping(void*) as you don’t have to cast the user
> pointer to a uint64_t.
>
> I’ll agree that the reverse mapping is perhaps not that useful, at least I
> don’t use it. But I do use the addGlobalMapping(const GlobalValue
> *GV, void *Addr) functions in my code.
>
> Note, even though this layer accepts void*, they are all converted to and
> stored as uint64_t internally.
>
>
>
>
> On Aug 26, 2015, at 1:59 AM, Lang Hames <lhames at gmail.com> wrote:
>
> Hi Andy,
>
> Thanks for working on this. I think ORC can get away with a much simpler
> global mapping scheme than ExecutionEngine had: ORC layers should deal only
> with string symbol names and TargetAddresses, never Value*s or void*s
> (though we can provide free functions for convenience to make it easy to
> use these). The full interface to the GlobalMappingLayer should just be: {
> <Constructor>, setGlobalMapping(Symbol, Address),
> removeGlobalMapping(Symbol), clearGlobalMappings(), addModuleSet,
> findSymbol, findSymbolIn, emitAndFinalize, and removeModule }. I don't
> think we need the reverse mapping: ORC needs a way to get symbols from
> addresses, but to go the other way you would usually attach debug info,
> rather than maintaining a reverse symbol table. Finally, this should be a
> module layer (like IRTransformLayer) rather than an ObjectLayer.
>
> I'm happy to adapt your patch with this in mind if you like - I believe
> the Kaleidoscope example would still work as expected with the changes I
> would make. Otherwise if you'd like to update the patch I'd be happy to
> review the changes too.
>
> Cheers,
> Lang.
>
>
> On Tue, Aug 25, 2015 at 2:41 PM, Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Andy, David,
>>
>> I have spotted it, I've just been flat out with the Kaleidoscope update.
>> I'm planning to review this this evening. :)
>>
>> - Lang.
>>
>>
>> On Tue, Aug 25, 2015 at 2:33 PM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>>
>>> +Lang to the actual 'to' line so he's got a greater chance of spotting it
>>>
>>> On Tue, Aug 25, 2015 at 2:31 PM, Andy Somogyi via llvm-commits <
>>> llvm-commits at lists.llvm.org> wrote:
>>>
>>>> Hey Lang,
>>>>
>>>> Would you mind having a look at this patch, it adds a new
>>>> GlobalMappingLayer to Orc, and it can be used in the new Kaleidoscope
>>>> updates to add existing global mappings like were possible with the
>>>> previous JIT ExecutionEngine.
>>>>
>>>>
>>>>
>>>> On Aug 22, 2015, at 1:29 AM, Andy Somogyi <andy.somogyi at gmail.com>
>>>> wrote:
>>>>
>>>> Attached is a patch that contains the new GlobalMappingLayer for Orc.
>>>>
>>>> This layer allows existing global values to be added and resolved in
>>>> the Orc JIT just like it was possible with ExecutionEngine. The Orc
>>>> kaleidoscope example was updated to use the new GlobalMappingLayer, and
>>>> actually use the three defined external functions.
>>>>
>>>> The new layer contains all the functionality that ExecutionEngine had,
>>>> and with this layer, it should be very straightforward to finish the
>>>> OrcMCJITReplacement to reference existing C functions and data.
>>>>
>>>>
>>>> <0001-New-GlobalMappingLayer-to-allow-existing-functions-t.patch>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>
>>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150827/7f73277a/attachment.html>


More information about the llvm-commits mailing list