[PATCH] New GlobalMappingLayer for Orc

[Andy Somogyi via llvm-commits]

Thanks, looks good, except the LLVM StringMap much more efficient then the general std::map as the LLVM StringMap is optimized for string lookups. 

StringMap is constant time (a very fast constant time based on testing) vs Log(n) for std::map

I would change std::map<std::string, TargetAddress> to StringMap<TargetAddress>


> On Aug 27, 2015, at 6:25 PM, Lang Hames <lhames at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <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/3037aa7e/attachment.html>