[LLVMdev] [PROPOSAL] LLVM multi-module support

[Tobias Grosser]

On 07/26/2012 04:49 PM, Justin Holewinski wrote:
> I'm not convinced that having multi-module IR files is the way to go.
>   It just seems like a lot of infrastructure/design work for little
> gain.  Can the embedded modules have embedded modules themselves?  How
> deep can this go?  If not, then the embedded LLVM IR language is really
> a subset of the full LLVM IR language.  How do you share variables
> between parent and embedded modules?

I don't have final answers to these questions, but here my current 
thoughts: I do not see a need for deeply nested modules, but I also 
don't see a big problem. Variables between parent and embedded modules 
are not shared. They are within separate address spaces.

> I feel that this can be better solved by just using separate IR modules.
>   For your purposes, the pass that generates the device code can simply
> create a new module and the host code can refer to the generated code by
> name.  Then, you can run each module through opt and llc individually,
> and then link them together somehow, like Dmitry's use of ELF
> symbols/sections.  This is exactly how CUDA binaries work; device code
> is embedded into the host binary as special ELF sections.  This would be
> a bit more work on the part of your toolchain to make sure opt and llc
> and executed for each produced module, but the changes are far fewer
> than supporting sub-modules in a single IR file.  This also has the
> benefit that you do not need to change LLVM at all for this to work.
>
> Is there some particular use-case that just won't work without
> sub-module support?  I know you like using the example of "clang -o - |
> opt -o - | llc" but I'm just not convinced that retaining the ability to
> pipe tools like that is justification enough to change such a
> fundamental part of the LLVM system.

As I mentioned to Duncan, I agree with you that for a specific tool 
chain, the approach you mentioned is probably best. However, I am aiming 
for a more generic approach, which aims for optimizer plugins that can 
be used in various LLVM-based compilers, without the need for larger 
changes to each these compilers. Do you think that is a useful goal?

Thanks for your feedback
Tobi