[LLVMdev] [PROPOSAL] LLVM multi-module support

[Dmitry N. Mikushin]

Hi Tobias,

> What is the benefit of having the kernel embedded as data symbol in the
ELF object, in contrast to having it as a global variable

This is for conventional link step & LTO. During compilation we allow
kernels to depend on each other, which is resolved during linking. The
whole process is built on top of gcc and its existing collect2/lto1
mechanisms. As result, we have hybrid objects/libraries/binaries containing
two independent representations: regular binary output from gcc and a set
of LLVM IR of kernels operated by their own entry point. And now the code
is not in the data section, but in special one, similar to __gnu_lto_v1 for
gcc's LTO.

One question I realized while replying to yours: do you see your team more
focusing on infrastructure things or on polyhedral analysis development?

The quality of CLooG/Polly is what we ultimately rely on in the _first_
place. All other things are _a_lot_ simpler. You will see: ecosystems,
applications and testbeds will grow around themselves, once the core
concepts is strong. There is probably no need to spend resources on leading
the way for them in engineering topics. But they may wither soon, if math
is not growing with the same speed. Just an opinion.

Best,
- D.

2012/7/29 Tobias Grosser <tobias at grosser.es>

> On 07/26/2012 04:12 PM, Dmitry N. Mikushin wrote:
>
>> In our project we combine regular binary code and LLVM IR code for
>> kernels, embedded as a special data symbol of ELF object. The LLVM IR
>> for kernel existing at compile-time is preliminary, and may be optimized
>> further during runtime (pointers analysis, polly, etc.). During
>> application startup, runtime system builds an index of all kernels
>> sources embedded into the executable. Host and kernel code interact by
>> means of special "launch" call, which does not only
>> optimize&compile&execute the kernel, but first makes an estimation if it
>> is worth to, or better to fall back to host code equivalent.
>>
>> Proposal made by Tobias is very elegant, but it seems to be addressing
>> the case when host and sub-architectures' code exist in the same time.
>> May I kindly point out that to our experience the really efficient
>> deeply specialized sub-architectures code may simply not exist at
>> compile time, while the generic baseline host code always can.
>>
>
> Hi Dimitry,
>
> the proposal did not mean to say that all code needs to be optimized and
> target code generate at compile time. You may very well retain some kernels
> as LLVM-IR code and pass this code to your runtime system (similar how CUDA
> or OpenCL currently accept kernel code).
>
> Btw, one question I always wanted to ask: What is the benefit of having
> the kernel embedded as data symbol in the ELF object, in contrast to having
> it as a global variable (which is then passed to the run-time). I know cell
> used mainly elf symbols, but e.g. OpenCL reads kernels by passing a pointer
> to the kernel string to the run-time library. Can you point out the
> difference to me?
>
> Cheers and thanks
> Tobi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120730/ab8298d7/attachment.html>