[LLVMdev] [PROPOSAL] LLVM multi-module support

[Tobias Grosser]

On 07/26/2012 08:39 PM, dag at cray.com wrote:
> Tobias Grosser <tobias at grosser.es> writes:
>
>> o Modeling sub-architectures on a per-function basis
>>
>> Functions could be specialized for a certain sub-architecture. This is
>> helpful to have certain functions optimized e.g. with AVX2 enabled, but
>> the general program being compiled for a more generic architecture.
>> We do not address per-function annotations in this proposal.
>
> Could this be accomplished using a separate module for the specialized
> function of interest under your proposal?

In my proposal, different modules have different address spaces. Also, I 
don't aim to support function calls across module boundaries. So having 
a separate module for this function does not seem to be a solution.

>> ## Proposed solution ##
>>
>> To bring multi-module support to LLVM, we propose to add a new type
>> called 'llvmir' to LLVM-IR. It can be used to embed LLVM-IR submodules
>> as global variables.
>>
>> ------------------------------------------------------------------------
>> target datalayout = ...
>> target triple = "x86_64-unknown-linux-gnu"
>>
>> @llvm_kernel = private unnamed_addr constant llvm_kernel {
>>     target triple = nvptx64-unknown-unknown
>>     define internal ptx_kernel void @gpu_kernel(i8* %Array) {
>>       ...
>>     }
>> }
>> ------------------------------------------------------------------------
>>
>> By default the global will be compiled to a llvm string stored in the
>> object file. We could also think about translating it to PTX or AMD's
>> HSA-IL, such that e.g. PTX can be passed to a run-time library.
>
> Hmm...I'm not sure about this model.  Not every accelerator execution
> model out there takes code as a string.  Some want natively-compiled
> binaries.

If LLVM provides an object code emitter for the relevant back-end, we 
could also think about emitting native binaries. Storing the assembly as 
a string is just a 'default' output.

>>   From my point of view, Peters idea allows us to add multi-module
>> support in a way that allows us to reach the goals described above.
>> However, to properly design and implement it, early feedback would be
>> valuable.
>
> I really don't like this at first glance.  Anything that results in a
> string means that we can't use normal tools to manipulate it.
> I
> understand the string representation is desirable for some targets but
> it seems to really cripple others.  The object file output should at
> least be configurable.  Some targets might even want separate asm files
> for the various architectures.

I see 'string' just as a default output, but would have hoped we could 
provide other outputs as needed. Do you see any reason, why we could not 
emit native code for some of the embedded sub-modules?

Thanks for your feedback
Tobi