[LLVMdev] [PROPOSAL] LLVM multi-module support (original) (raw)

Tobias Grosser tobias at grosser.es
Sun Jul 29 12:38:57 PDT 2012

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 = "x8664-unknown-linux-gnu" @llvmkernel = private unnamedaddr constant llvmkernel { target triple = nvptx64-unknown-unknown define internal ptxkernel void @gpukernel(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

More information about the llvm-dev mailing list