<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-03-03 10:19 GMT-05:00 Ronan Keryell via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>>>>> On Thu, 3 Mar 2016 18:19:43 +0700, C Bergström via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> said:<br>
<br>
C> On Thu, Mar 3, 2016 at 5:50 PM, Ronan KERYELL via cfe-dev<br>
<span class=""> C> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
<br>
>> Just to be sure to understand: you are thinking about being able<br>
>> to outline several "languages" at once, such as CUDA *and*<br>
>> OpenMP, right ?<br>
>><br>
>> I think it is required for serious applications. For example, in<br>
>> the HPC world, it is common to have hybrid multi-node<br>
>> heterogeneous applications that use MPI+OpenMP+OpenCL for<br>
>> example. Since MPI and OpenCL are just libraries, there is only<br>
>> OpenMP to off-load here. But if we move to OpenCL SYCL instead<br>
>> with MPI+OpenMP+SYCL then both OpenMP and SYCL have to be managed<br>
>> by the Clang off-loading infrastructure at the same time and be<br>
>> sure they combine gracefully...<br>
>><br>
>> I think your second proposal about (un)bundling can already<br>
>> manage this.<br>
>><br>
>> Otherwise, what about the code outlining itself used in the<br>
>> off-loading process? The code generation itself requires to<br>
>> outline the kernel code to some external functions to be compiled<br>
>> by the kernel compiler. Do you think it is up to the programmer<br>
>> to re-use the recipes used by OpenMP and CUDA for example or it<br>
>> would be interesting to have a third proposal to abstract more<br>
>> the outliner to be configurable to handle globally OpenMP, CUDA,<br>
>> SYCL...?<br>
<br>
</span> C> Some very good points above and back to my broken record..<br>
<br>
C> If all offloading is done in a single unified library -<br>
C> a. Lowering in LLVM is greatly simplified since there's ***1***<br>
C> offload API to be supported A region that's outlined for SYCL,<br>
C> CUDA or something else is essentially the same thing. (I do<br>
C> realize that some transformation may be highly target specific,<br>
C> but to me that's more target hw driven than programming model<br>
C> driven)<br>
<br>
C> b. Mixing CUDA/OMP/ACC/Foo in theory may "just work" since the<br>
C> same runtime will handle them all. (With the limitation that if<br>
C> you want CUDA to *talk to* OMP or something else there needs to<br>
C> be some glue. I'm merely saying that 1 application with multiple<br>
C> models in a way that won't conflict)<br>
<br>
C> c. The driver doesn't need to figure out do I link against some<br>
C> or a multitude of combining/conflicting libcuda, libomp,<br>
C> libsomething - it's liboffload - done<br>
<br>
Yes, a unified target library would help. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
C> The driver proposal and the liboffload proposal should imnsho be<br>
C> tightly coupled and work together as *1*. The goals are<br>
C> significantly overlapping and relevant. If you get the liboffload<br>
C> OMP people to make that more agnostic - I think it simplifies the<br>
C> driver work.<br>
<br>
So basically it is about introducing a fourth unification: liboffload.<br>
<br>
A great unification sounds great.<br>
My only concern is that if we tie everything together, it would increase<br>
the entry cost: all the different components should be ready in<br>
lock-step.<br>
If there is already a runtime available, it would be easier to start<br>
with and develop the other part in the meantime.<br>
So from a pragmatic agile point-of-view, I would prefer not to impose a<br>
strong unification.<br>
In the proposal of Samuel, all the parts seem independent.<br></blockquote><div><br></div><div>I agree with Ronan. Having a unified library is a discussion that is worth having, but the design of something like that has to be incremental. And in order for that to happened it has to start from what is already available or about to be available upstream.</div><div><br></div><div>I don't think that the decisions about the library affect the driver much. Specifying a different library in a given toolchain is only a one-line change.</div><div><br></div><div>I'd rather have the library discussion in a different mailing list (maybe OpenMP) because, as Andrey said, these (driver and library) are (and in my opinion should) be two separate efforts. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
C> ------ More specific to this proposal - device<br>
C> linker vs host linker. What do you do for IPA/LTO or whole<br>
C> program optimizations? (Outside the scope of this project.. ?)<br>
<br>
Ouch. I did not think about it. It sounds like science-fiction for<br>
now. :-) Probably outside the scope of this project..<br>
<br>
Are you thinking to having LTO separately on each side independently,<br>
host + target? Of course having LTO on host and target at the same time<br>
seems trickier... :-) But I can see here a use case for "constant<br>
specialization" available in SPIR-V, if we can have some simple host<br>
LTO knowledge about constant values flowing down into device IR.<br>
<br>
For non link-time IPA, I think it is simpler since I guess the<br>
programming models envisioned here are all single source, so we can<br>
apply most of the IPA *before* outlining I hope. But perhaps wild<br>
preprocessor differences for host and device may cause havoc here?<br></blockquote><div><br></div><div>LTO is coupled to the toolchain and which plugins the linker supports. In the OpenMP implementation we prototype we have in github we have LTO enabled by the the driver - it uses llvm-link to produce a single piece of IR before calling the backend. We could do something similar because expecting a linker to have LTO plugins enabled for every possible device seems unlikely. I guess that would be a separate proposal. :)</div><div><br></div><div>I understand why we would like to have LTO before outlining (propagate info from host to device code). However, in the way things currently are (frontend does outlining) that would be hard. So, at least, I hope to have clang providing the maximum information through attributes to outlined kernels.</div><div><br></div><div>Thanks again,</div><div>Samuel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
--<br>
Ronan KERYELL<br>
Xilinx Research Labs, Dublin, Ireland<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>