[LLVMdev] [PROPOSAL] LLVM multi-module support
dag at cray.com
dag at cray.com
Thu Jul 26 08:09:32 PDT 2012
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?
> ## 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.
> 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.
-Dave
More information about the llvm-dev
mailing list