<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks, looks good, except the LLVM StringMap much more efficient then the general std::map as the LLVM StringMap is optimized for string lookups. <div class=""><br class=""></div><div class="">StringMap is constant time (a very fast constant time based on testing) vs Log(n) for std::map</div><div class=""><br class=""></div><div class="">I would change std::map<std::string, TargetAddress> to StringMap<TargetAddress></div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Aug 27, 2015, at 6:25 PM, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Andy,<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">class MyJIT {</font></div><div class=""><font face="monospace, monospace" class=""> // Lower orc layers.</font></div><div class=""><font face="monospace, monospace" class=""> GlobalMappingLayer<...> MappingLayer;</font></div><div class=""><font face="monospace, monospace" class=""> // Any higher orc layers.</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> addGlobalMapping(const GlobalValue *GV, void *Addr) {</font></div><div class=""><font face="monospace, monospace" class=""> MappingLayer.setGlobalMapping(mangle(GV),</font></div><div class=""><font face="monospace, monospace" class=""> static_cast<TargetAddress>(</font></div><div class=""><font face="monospace, monospace" class=""> reinterpret_cast<uintptr_t>(Addr)));</font></div><div class=""><font face="monospace, monospace" class=""> }</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class="">};</font></div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Lang.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Aug 26, 2015 at 7:15 PM, Andy Somogyi <span dir="ltr" class=""><<a href="mailto:andy.somogyi@gmail.com" target="_blank" class="">andy.somogyi@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">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 :) )<div class=""><br class=""></div><div class="">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 </div><div class=""><br class=""></div><div class="">addGlobalMapping(const GlobalValue *GV, void *Addr)</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Note, even though this layer accepts void*, they are all converted to and stored as uint64_t internally. </div><span class=""><div class=""><br class=""></div><div class=""> <br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 26, 2015, at 1:59 AM, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi Andy,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Lang.</div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 25, 2015 at 2:41 PM, Lang Hames <span dir="ltr" class=""><<a href="mailto:lhames@gmail.com" target="_blank" class="">lhames@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Hi Andy, David,<div class=""><br class=""></div><div class="">I have spotted it, I've just been flat out with the Kaleidoscope update. I'm planning to review this this evening. :)</div><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">- Lang.</div><div class=""><br class=""></div></font></span></div><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 25, 2015 at 2:33 PM, David Blaikie <span dir="ltr" class=""><<a href="mailto:dblaikie@gmail.com" target="_blank" class="">dblaikie@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">+Lang to the actual 'to' line so he's got a greater chance of spotting it</div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="">On Tue, Aug 25, 2015 at 2:31 PM, Andy Somogyi via llvm-commits <span dir="ltr" class=""><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class=""><div style="word-wrap:break-word" class="">Hey Lang, <div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On Aug 22, 2015, at 1:29 AM, Andy Somogyi <<a href="mailto:andy.somogyi@gmail.com" target="_blank" class="">andy.somogyi@gmail.com</a>> wrote:</div><br class=""></div></div><div class=""><div class=""><div class=""><div style="word-wrap:break-word" class=""><span style="font-family:Menlo-Regular;font-size:11px" class="">Attached is a patch that contains the new GlobalMappingLayer for Orc. </span><br style="font-family:Menlo-Regular;font-size:11px" class=""><br style="font-family:Menlo-Regular;font-size:11px" class=""><span style="font-family:Menlo-Regular;font-size:11px" class="">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. </span><div class=""><font face="Menlo-Regular" class=""><span style="font-size:11px" class=""><br class=""></span></font></div><div class=""><font face="Menlo-Regular" class=""><span style="font-size:11px" class="">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. </span><br class=""></font><div class=""><br class=""></div><div class=""><br style="font-family:Menlo-Regular;font-size:11px" class=""></div></div></div></div></div><span class=""><0001-New-GlobalMappingLayer-to-allow-existing-functions-t.patch></span><div style="word-wrap:break-word" class=""><div class=""><div class=""></div></div></div></div></blockquote><br class=""></div></div></div></div><br class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""></div></div></div><br class=""></div></div>_______________________________________________<br class="">
llvm-commits mailing list<br class="">
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank" class="">llvm-commits@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></div></span></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>