[cfe-dev] clang-offload-bundler

[Simone Atzeni via cfe-dev]

Hi Jonas,

The clang-offload-bundler does not look like it uses the ELF sections (both
the version of trunk and Ykt), it looks like it just concatenate the object
files into one file, but I might be wrong or if not hopefully this will be
changed later.
At the moment, even though offloading to GPUs is not working on Clang, the
driver seems like is doing something different than any other compiler.
I cced Doru, maybe he can add more about this.

I am just asking because we are going to add GPUs support on Flang and of
course we want to keep clang and flang compatible.

Thanks.
Simone

On Thu, Jan 11, 2018 at 1:00 PM, Jonas Hahnfeld <hahnjo at hahnjo.de> wrote:

> Hi Simone,
>
> the same answers as always:
> 1. Offloading to GPUs is not yet working with Clang trunk.
> 2. Most of this has already been discussed on the mailing list or
> described in publications. In short, clang-offload-bundler should also use
> ELF sections for object files. And AFAIK, IBM XL uses the same mechanisms
> in most cases.
>
> Jonas
>
>
> Am 2018-01-11 19:15, schrieb Simone Atzeni via cfe-dev:
>
>> Hi all,
>>
>> I have been playing with the clang driver to see how it performs the
>> compilations for an OpenMP program with target offloading (for NVidia
>> GPU).
>>
>> I noticed the use of the tool 'clang-offload-bundler' which seems to
>> bundle together the object files for the host and for the device.
>> In particular, if I use -c my foo.o will be a bundle of foo-x86_64.o
>> and foo-cuda.o, and at link time it will unbundle the foo.o to obtain
>> back the two object files.
>>
>> Now, if I put my foo.o for example in a static library clang does not
>> work because it does not know how to unbundle the object files from
>> the library.
>>
>> Other compilers, such as IBM XL create a specific section in the ELF
>> to store the device code, in this way we always have one object file
>> and there is no need to bundle/unbundle.
>> Also if a object file/library was compiled with XL it can not be
>> linked with clang and/or viceversa.
>>
>> So, am I doing something wrong, or is this the status of the clang
>> driver?
>> Is the clang-offload-bundler the official choice to manage device
>> code?
>> If my analysis is correct, what's the workaround?
>>
>> Thanks!
>> Best,
>> Simone
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180111/4ef35f86/attachment.html>