<div dir="ltr">Hi Andy,<div><br></div><div>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><br></div><div><font face="monospace, monospace">class MyJIT {</font></div><div><font face="monospace, monospace"> // Lower orc layers.</font></div><div><font face="monospace, monospace"> GlobalMappingLayer<...> MappingLayer;</font></div><div><font face="monospace, monospace"> // Any higher orc layers.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> addGlobalMapping(const GlobalValue *GV, void *Addr) {</font></div><div><font face="monospace, monospace"> MappingLayer.setGlobalMapping(mangle(GV),</font></div><div><font face="monospace, monospace"> static_cast<TargetAddress>(</font></div><div><font face="monospace, monospace"> reinterpret_cast<uintptr_t>(Addr)));</font></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">};</font></div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 7:15 PM, Andy Somogyi <span dir="ltr"><<a href="mailto:andy.somogyi@gmail.com" target="_blank">andy.somogyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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><br></div><div>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><br></div><div>addGlobalMapping(const GlobalValue *GV, void *Addr)</div><div><br></div><div>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><br></div><div>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><br></div><div>Note, even though this layer accepts void*, they are all converted to and stored as uint64_t internally. </div><span class=""><div><br></div><div> <br><div><br></div><div><br><div><blockquote type="cite"><div>On Aug 26, 2015, at 1:59 AM, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Hi Andy,<div><br></div><div>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><br></div><div>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><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 2:41 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Andy, David,<div><br></div><div>I have spotted it, I've just been flat out with the Kaleidoscope update. I'm planning to review this this evening. :)</div><span><font color="#888888"><div><br></div><div>- Lang.</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 2:33 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+Lang to the actual 'to' line so he's got a greater chance of spotting it</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Aug 25, 2015 at 2:31 PM, Andy Somogyi via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div style="word-wrap:break-word">Hey Lang, <div><br></div><div>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><br></div><div><br><div><br></div><div><div><blockquote type="cite"><div><div><div>On Aug 22, 2015, at 1:29 AM, Andy Somogyi <<a href="mailto:andy.somogyi@gmail.com" target="_blank">andy.somogyi@gmail.com</a>> wrote:</div><br></div></div><div><div><div><div style="word-wrap:break-word"><span style="font-family:Menlo-Regular;font-size:11px">Attached is a patch that contains the new GlobalMappingLayer for Orc. </span><br style="font-family:Menlo-Regular;font-size:11px"><br style="font-family:Menlo-Regular;font-size:11px"><span style="font-family:Menlo-Regular;font-size:11px">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><font face="Menlo-Regular"><span style="font-size:11px"><br></span></font></div><div><font face="Menlo-Regular"><span style="font-size:11px">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></font><div><br></div><div><br style="font-family:Menlo-Regular;font-size:11px"></div></div></div></div></div><span><0001-New-GlobalMappingLayer-to-allow-existing-functions-t.patch></span><div style="word-wrap:break-word"><div><div></div></div></div></div></blockquote><br></div></div></div></div><br><div style="word-wrap:break-word"><div><div></div></div></div><br></div></div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></span></div></blockquote></div><br></div>