Is ModuleBuilder useful to anyone?

Following

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140825/113355.html

In tree, ModuleBuilder has one user (+test) only, the BackendConsumer.
The interaction between the two classes complicates BackendConsumer logic. For instance, both hold the same Module * in two different std::unique_ptr and dance around this problem to avoid releasing it twice or none.

Out of tree, is ModuleBuilder limited functionality useful to any project?

Personally I’m not using it, but I recall that cling might be?

I have a hard dependency on it and have no idea how I could handle losing that API

True, I checked now and cling uses the ModuleBuilder. It can’t switch to BackendConsumer as it’s still using the old JIT.

The old JIT has been removed, so that should not hold a decision on
what to do on trunk.

Cheers,
Rafael

I am trying to eliminate the consumer of consumer pattern we have where BackendConsumer is mostly a thin layer around a ModuleBuilder it creates for itself. Most of the additional functionality being in HandleTranslationUnit calling EmitBackendOutput to create bc, ll or object files. Most the input aguments of BackendConsumer are needed for CreateLLVMCodeGen only.

EmitBackendOutput already supports a “Backend_EmitNothing” action. If we merge BackendConsumer functionality into ModuleBuilder and eliminate BackendConsumer , I think that every existing ModuleBuilder could continue using “new” ModuleBuilder with Action = Backend_EmitNothing and OS = nullptr just the same.

Mark, would that work for you?

Wait, ModuleBuilder? I was getting confused with CodeGenModule. I have no use for the ModuleBuilder class.

Thanks for asking! Yes cling uses it. We are planning to migrate soon (ish) to MCJIT and IIUC we could get rid of the ModuleBuilder.
Vassil

Technically the old JIT is gone and if we update to newer llvm (which is the plan) we will have to migrate to MCJIT. Given that, would it be easier to avoid using ModuleBuilder? Vassil

True, I checked now and cling uses the ModuleBuilder. It can't switch to
BackendConsumer as it's still using the old JIT.

The old JIT has been removed, so that should not hold a decision on
what to do on trunk.

I agree.
Vassil

ModuleBuilder is an ASTConsumer wrapping CodeGenModule to generate IR. It has two types of users (we know of so far). The first is in-tree BackendConsumer, generating object and assembler files and the second is MCJIT (and the old JIT in previous versions).

Since BackendConsumer can generate no file (Action = Backend_EmitNothing) it may make sense to merge BackendConsumer into ModuleBuilder and remove BackendConsumer altogether. This should work with JIT just the same and eliminate the BackendConsumer-ModuleBuilder interface.