<div dir="ltr">Hi Manoel,<div><br></div><div>CC'ing the dev list again.</div><div><br></div><div>When you say that you are using <span style="font-size:13px">LLVMOrcJit, what do you mean? Are you constructing your own stack along the lines of the Kaleidoscope tutorials? Or are you using OrcMCJITReplacement? You should be able to do what you want with your own stack, but the OrcMCJITReplacement class has to replicate MCJIT's behavior, which includes taking ownership of Modules.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Assuming you're using your own stack, I have some observations:</span></div><div><span style="font-size:13px"><br></span></div><div>For simple expressions, hopefully you can recognize forms that you have already compiled and reuse the cached code. Then there's no additional work to do.</div><div><br></div><div>For expressions that haven't been compiled yet I would expect the cost of compiling the expression to dwarf the cost of building the Module. Have you profiled your program? Is Module construction actually showing up as a source of high overhead?</div><div><br></div><div>If constructing Modules really is proving to be a big time-sink, some of the Orc layers* allow you to re-use a Module as many times as you like. The ModuleSet type for the addModuleSet methods is a template parameter, so whether or not you pass in ownership is up to you. E.g.</div><div><br></div><div>(1) Pass vector of unique_ptrs. Ownership of the Modules is transferred to the JIT, and Modules cannot be modified.</div><div><font face="monospace, monospace">std::vector<std::unique_ptr<llvm::Module>> Modules;</font></div><div><font face="monospace, monospace">// ...</font></div><div><font face="monospace, monospace">addModuleSet(std::move(Modules), ...);</font></div><div><br></div><div>(2) Pass a vector of raw pointers. Ownership is not transferred to the JIT, and Modules can be modified and re-added:</div><div><font face="monospace, monospace">std::vector<llvm::Module*> Modules;</font></div><div><font face="monospace, monospace">// ...</font></div><div><font face="monospace, monospace">addModuleSet(std::move(Modules), ...);</font></div><div><font face="monospace, monospace">// ... Modify modules...</font></div><div><font face="monospace, monospace">addModuleSet(std::move(Modules), ...);</font></div><div><br></div><div><br></div><div>*The ownership models for each of the layers are as follows:</div><div><br></div><div>1) ObjectLinkingLayer - Totally ownership agnostic. Object pointers discarded after use. If the pointer type is unique_ptr this will destroy the object in the process.</div><div><br></div><div>2) IRCompilingLayer - Totally ownership agnostic. Module pointers are discarded after use. If the pointer type is unique_ptr the will destroy the module in the process.</div><div><br></div><div>3) LazyEmittingLayer - Ownership agnostic API with contract: Modules can only be modified and re-added after they've been either (a) compiled, or (b) erased. Adding a module then modifying it before it is compiled or erased is undefined.</div><div><br></div><div>4) CompileOnDemandLayer - Owning. Modules cannot be modified after being added. </div><div><br></div><div>From what I understand of your use case I think you want the simplest stack - just the ObjectLinking and IRCompiling layers. These should be totally compatible with retaining ownership and modify existing modules.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 7:12 AM, Manoel Teixeira <span dir="ltr"><<a href="mailto:mbsteixeira@gmail.com" target="_blank">mbsteixeira@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"><br><div> Hi,</div><div><br></div><div>I am using the LLVMOrcJit now, but the problems are not solved.</div><div><br></div><div>See this example :</div><div><div> /* string1 string2 */</div><div>Static Function GetDataBaseElement(_cDataSource,_cDataSource)</div><div>Local _xRet /* not typed variable */</div><div><br></div><div>_xRet := &(_cDataSource+"->"+_cCampo) </div><div><br></div><div>Return(_xRet)</div></div><div><br></div><div>This expression (_cDataSource+"->"+_cCampo) concatenates three strings, producing something like "TABLEDATASETNAME->FIELDNAME". After that, the token & indicates that I have to compile the string expression and execute it. Once it's compiled, the result will be TABLEDATASETPOINTER->FIELDNAMEPOINTER.</div><div><br></div><div>This kind of routine is used all the time by the developers to access data. If I already have compiled the expression I justly get the emitted code and it's executed else it's compiled and put on cache.</div><div>If I have to create and destroy a llvm::Module every time that I need to compile such kind of expression, the perfomance of the the user application will be very bad.</div><div><br></div><div>Cheers,</div><div>Manoel</div></div>
</blockquote></div><br></div>