[LLVMdev] Making it possible to clear the LLVMContext

[Marcello Maggioni]

Hello,

I'm trying to develop a way to reliably clean the LLVMContext in order to
make it possible to use it multiple times.

LLVMContext itself is an almost empty object delegating almost all its
content to LLVMContextImpl.
This makes it very clean ideally, because clearing the LLVMContext would be
as easy as deleting the LLVMContextImpl and creating a new one.

The problem is that for some reason which I'm not aware of LLVMContextImpl
is actually exposed as a public pointer in the LLVMContext interface,making
it publicly available to objects that use it directly (this seems to happen
quite a lot in the codebase).

In LLVMContext the LLVMContextImpl is contained in a pImpl pointer that is
const (the pointer itself can't be changed) and I guess this is some kind
of protection against object replacing the LLVMContextImpl directly, which
stops us from just deleting it + getting a new one.
In addition to that, being pImpl public, there is no guarantee that objects
don't rely on pImpl remaining always the same pointer.

This makes it more difficult to clear LLVMContext.

An approach I thought of could be adding a clear() method to LLVMContext
that:
 - Calls directly the destructor of LLVMContextImpl on the pImpl object
 - Uses a placement new to reinitialize the object.
 - Recreates the fixed metadata kinds like the LLVMContext constructor does

I'm attaching a patch that show this approach in this mail.

I would like to know a general idea about what people think about this and
see what people think would be the best approach would be.

Thanks,
Marcello
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/9c510069/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clear_llvm_context.patch
Type: application/octet-stream
Size: 2310 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140624/9c510069/attachment.obj>