<div dir="ltr">Something like, keeping the compiler alive for a many compilation sessions, using the same LLVMContext, but without the problem of accumulating data in the LLVMContext that would slowly fill up the memory.<div>
<br></div><div>This as much I can enter into details that I can :/</div><div><br></div><div>Probably this is also a quite common use case scenario too.</div><div><br></div><div>Marcello</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2014-06-24 18:52 GMT+01:00 Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, this is likely going to have at least some of the same problems<br>
that Bill ran into when he tried to update a TargetMachine by<br>
placement newing a new one into it.<br>
<br>
Can you elaborate a bit more about what you're trying to do? (I<br>
realize this may be difficult for reasons.)<br>
<span class="HOEnZb"><font color="#888888"><br>
-eric<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, Jun 24, 2014 at 10:44 AM, Marcello Maggioni <<a href="mailto:hayarms@gmail.com">hayarms@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> the need here is to have a single LLVMContext used for multiple<br>
> compilations.<br>
><br>
> You make a good point about that by the way. If there are outstanding users<br>
> cleaning the context under their seats might still pose a risk to them, and<br>
> in that case deleting + newing a new LLVMContextImpl might actually not be<br>
> very different.<br>
><br>
> Marcello<br>
><br>
> 2014-06-24 17:14 GMT+01:00 David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>>:<br>
><br>
>> What're the situation in which you need to clear it? If there are<br>
>> outstanding users of it (given that you mention clients possibly<br>
>> holding references to the pimpl, it sounds like you might have<br>
>> outstanding users) then wouldn't they be at risk of breaking if you<br>
>> mutate the LLVMContext underneath them?<br>
>><br>
>> & if you don't have outstanding users, is there any particular benefit<br>
>> to resetting the LLVMContext compared to just making a new one?<br>
>><br>
>> On Tue, Jun 24, 2014 at 7:18 AM, Marcello Maggioni <<a href="mailto:hayarms@gmail.com">hayarms@gmail.com</a>><br>
>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > I'm trying to develop a way to reliably clean the LLVMContext in order<br>
>> > to<br>
>> > make it possible to use it multiple times.<br>
>> ><br>
>> > LLVMContext itself is an almost empty object delegating almost all its<br>
>> > content to LLVMContextImpl.<br>
>> > This makes it very clean ideally, because clearing the LLVMContext would<br>
>> > be<br>
>> > as easy as deleting the LLVMContextImpl and creating a new one.<br>
>> ><br>
>> > The problem is that for some reason which I'm not aware of<br>
>> > LLVMContextImpl<br>
>> > is actually exposed as a public pointer in the LLVMContext<br>
>> > interface,making<br>
>> > it publicly available to objects that use it directly (this seems to<br>
>> > happen<br>
>> > quite a lot in the codebase).<br>
>> ><br>
>> > In LLVMContext the LLVMContextImpl is contained in a pImpl pointer that<br>
>> > is<br>
>> > const (the pointer itself can't be changed) and I guess this is some<br>
>> > kind of<br>
>> > protection against object replacing the LLVMContextImpl directly, which<br>
>> > stops us from just deleting it + getting a new one.<br>
>> > In addition to that, being pImpl public, there is no guarantee that<br>
>> > objects<br>
>> > don't rely on pImpl remaining always the same pointer.<br>
>> ><br>
>> > This makes it more difficult to clear LLVMContext.<br>
>> ><br>
>> > An approach I thought of could be adding a clear() method to LLVMContext<br>
>> > that:<br>
>> >  - Calls directly the destructor of LLVMContextImpl on the pImpl object<br>
>> >  - Uses a placement new to reinitialize the object.<br>
>> >  - Recreates the fixed metadata kinds like the LLVMContext constructor<br>
>> > does<br>
>> ><br>
>> > I'm attaching a patch that show this approach in this mail.<br>
>> ><br>
>> > I would like to know a general idea about what people think about this<br>
>> > and<br>
>> > see what people think would be the best approach would be.<br>
>> ><br>
>> > Thanks,<br>
>> > Marcello<br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>> ><br>
><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
</div></div></blockquote></div><br></div>