<div dir="ltr">Hi Justin,<div><br></div><div>It's great to have your feedback!</div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-03 17:09 GMT-05:00 Justin Lebar 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi, I'm one of the people working on CUDA in clang.<br>
<br>
In general I agree that the support for CUDA today is rather ad-hoc; it can<br>
likely be improved. However, there are many points in this proposal that I do<br>
not understand. Inasmuch as I think I understand it, I am concerned that it's<br>
adding a new abstractions instead of fixing the existing ones, and that this<br>
will result in a lot of additional complexity.<br>
<span class=""><br>
> a) Create toolchains for host and offload devices before creating the actions.<br>
><br>
> The driver has to detect the employed programming models through the provided<br>
> options (e.g. -fcuda or -fopenmp) or file extensions. For each host and<br>
> offloading device and programming model, it should create a toolchain.<br>
<br>
</span>Seems sane to me.<br>
<span class=""><br>
> b) Keep the generation of Actions independent of the program model.<br>
><br>
> In my view, the Actions should only depend on the compile phases requested by<br>
> the user and the file extensions of the input files. Only the way those<br>
> actions are interpreted to create jobs should be dependent on the programming<br>
> model. This would avoid complicating the actions creation with dependencies<br>
> that only make sense to some programming models, which would make the<br>
> implementation hard to scale when new programming models are to be adopted.<br>
<br>
</span>I don't quite understand what you're proposing here, or what you're trying to<br>
accomplish with this change.<br>
<br>
Perhaps it would help if you could give a concrete example of how this would<br>
change e.g. CUDA or Mac universal binary compilation?<br>
<br>
For example, in CUDA compilation, we have an action which says "compile<br>
everything below here as cuda arch sm_35". sm_35 comes from a command-line<br>
flag, so as I understand your proposal, this could not be in the action graph,<br>
because it doesn't come from the filename or the compile phases requested by<br>
the user. So, how will we express this notion that some actions should be<br>
compiled for a particular arch?<br></blockquote><div><br></div><div>This has two objectives. One is to avoid the creation of actions that are programming model specific. The other is to remove complexity from the action creation that would have to mix phases and different programming models DAG requirements - currently CUDA only requires one single dependency but if you have more programming models with different requirements and add separate compilation on top of that, the action generation will become complex and hard to scale. Just to clarify, I am not saying that creating actions for each programming model won't work, I just thing that doing this differently will ensure that adding new programming models will be less disruptive as the programming model specifics will be contained in a single place. </div><div><br></div><div>The way I see it is that an action just packs some information processed from a bunch of input info. However, creating an action specific for a programming model does not prevent you from having to have dedicated logic to deal with it when the jobs are created. So, given that the input info that results in an action is also available when the jobs are created, what I propose it to do all the programming model specifics in a single place. We already have a cache of results in the jobs builder that could help navigate the dependences and, even better, the queries this cache can provide can be completely agnostic of the programming model. <br></div><div><br></div><div>Let me try to give you an example on how this proposal would affect CUDA:</div><div><br></div><div>- Lets assume that the actions are generated the same way they are for the host. And that we already have in the driver the host toolchain and also the nvptx toolchain, each marked with a new toolchain kind "CUDA" (these toolchain were inferred from the options used to invoke the driver and/or file extensions). </div><div><br></div><div>- The jobs start to be created for the host as usual.</div><div><br></div><div>- Before the any job is constructed there would be a post-processing of the results, so that extra results could be appended if required by the programming model.</div><div><br></div><div>- This is what would happen in the post-processing function:</div><div>{</div><div> if (!isThisCUDAHostToolChain)</div><div> return;</div><div><br></div><div> if (!ActionIsCompile)</div><div> return;</div><div><br></div><div> if (InputActionDependence.type != TY_CUDA)</div><div> return;</div><div><br></div><div> //Make checks currently in buildCudaActions()</div><div><br></div><div> DevTC = getDeviceToolChainOfKind(CUDA);</div><div> Action *Asm = CachedResults().giveMeDependentAsmAction();</div><div> </div><div> for (c : CUDAComputeCapabilities ) {</div><div> NewResult = BuildJobsForAction(DevTC, Asm) </div><div> // Or maybe better</div><div> NewResult = BuildJobsForAction(DevTC, LinkAction(Asm))</div><div><br></div><div> Results.push_back(NewResult); </div><div> }</div><div>}</div><div><br></div><div>CachedResults would offer some extra functionality that is not programming model specific, and this would provide the same functionality the CUDA action is providing. Adding a new programming model would only require adding an instance of this post-process ( apart from the creation of the toolchains that would occur before anything starts to be done).</div><div><br></div><div>I agree these things are complicated to fully understand/explain based a summary in a email. I'll try to come up with a proposal-patch early next week so that we have something more concrete to discuss.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> c) Use unbundling and bundling tools agnostic of the programming model.<br>
><br>
> I propose a single change in the action creation and that is the creation of<br>
> a “unbundling” and "bundling” action whose goal is to prevent the user to<br>
> have to deal with multiple files generated from multiple toolchains (host<br>
> toolchain and offloading devices’ toolchains) if he uses separate compilation<br>
> in his build system.<br>
<br>
</span>I'm not sure I understand what "separate compilation" is here. Do you mean, a<br>
compilation strategy which outputs logically separate machine code for each<br>
architecture, only to have this code combined at link time? (In contrast to<br>
how we currently compile CUDA, where the device code for a file is integrated<br>
into the host code for that file at compile time?)<br></blockquote><div><br></div><div>That's correct. With separate compilation I also mean the ability to link device side code, using a device linker (nvlink for CUDA).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If that's right, then what I understand you're proposing here is that, instead<br>
of outputting N different object files -- one for the host, and N-1 for all our<br>
device architectures -- we'd just output one blob which clang would understand<br>
how to handle.<br></blockquote><div><br></div><div>Correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
For my part, I am highly wary of introducing a new file format into clang's<br>
output. Historically, clang (along with other compilers) does not output<br>
proprietary blobs. Instead, we output object files in well-understood,<br>
interoperable formats, such as ELF. This is beneficial because there are lots<br>
of existing tools which can handle these files. It also allows e.g. code<br>
compiled with clang to be linked with g++.<br>
<br>
Build tools are universally awful, and I sympathize with the urge not to change<br>
them. But I don't think this is a business we want the compiler to be in.<br>
Instead, if a user wants this kind of "fat object file", they could obtain one<br>
by using a simple wrapper around clang. If this wrapper's output format became<br>
widely-used, we could then consider supporting it directly within clang, but<br>
that's a proposition for many years in the future.<br></blockquote><div><br></div><div>I see the driver already as a wrapper, so I don't think it is not appropriate to use it. However, I think the creation of the blob should be done by an external tool, say, as it was a linker. I have an initial proposal in <a href="http://lists.llvm.org/pipermail/cfe-dev/2016-February/047548.html">http://lists.llvm.org/pipermail/cfe-dev/2016-February/047548.html</a>, but based on your input and also Jonas, I have to rethink a few things. </div><div><br></div><div>I agree when you say that you would like to have the blob working well with other tools. Jonas in some previous email also expressed this concern. I'd put it in this way: an bundled file should work as a normal host file, regardless of what device code it embeds.</div><div><br></div><div>For ELF files this works just fine:</div><div><br></div><div><div>clang a.c -c -o a.o</div><div>echo "Some offloading bytes" >> a.o</div><div>clang a.o -o a.out</div><div>a.out</div></div><div><br></div><div>However for other binary formats, we need to wrap in a different. Even for ELF, I agree putting the code in some section is more elegant. I'll investigate the possibilities to implement that.</div><div><br></div><div>In other side, we have text files. My opinion is that we should have something that is easy to read and edit. How would a bundled text file look like in your opinion?</div><div><br></div><div>Do you think have all the device code guarded as a comment in the bottom is acceptable? That would work well as a host file.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> d) Allow the target toolchain to request the host toolchain to be used for a given action.<br>
<br>
</span>Seems sane to me.<br>
<span class=""><br>
> e) Use a job results cache to enable sharing results between device and host toolchains.<br>
<br>
</span>I don't understand why we need a cache for job results. Why can we not set up<br>
the Action graph such that each node has the correct inputs? (You've actually<br>
sketched exactly what I think the Action graph should look like, for CUDA and<br>
OpenMP compilations.)<br></blockquote><div><br></div><div>I think what I explain above covers this one. If not, please let me know. Just to summarize, I'm not saying expressing things in Actions won't work, I just think that will be more complex if we have multiple programming models (all potentially used in the same compile) and separate compilation in place. We already have a cache in the jobs builder, I was just planing to leverage that. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> f) Intercept the jobs creation before the emission of the command.<br>
><br>
> In my view this is the only change required in the driver (apart from the<br>
> obvious toolchain changes) that would be dependent on the programming model.<br>
> A job result post-processing function could check that there are offloading<br>
> toolchains to be used and spawn the jobs creation for those toolchains as<br>
> well as append results from one toolchain to the results of some other<br>
> accordingly to the programming model implementation needs.<br>
<br>
</span>Again it's not clear to me why we cannot and should not represent this in the<br>
Action graph. It's that graph that's supposed to tell us what we're going to<br>
do.<br></blockquote><div><br></div><div>I guess covered this above, if not let me know.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> g) Reflect the offloading programming model in the naming of the save-temps files.<br>
<br>
</span>We already do this somewhat; e.g. for CUDA with save-temps, we'll output foo.s<br>
and foo-sm_35.s. Extending this to be more robust (e.g. including the triple)<br>
seems fine.<br></blockquote><div><br></div><div>Yes, programming model, host/device (in openmp same triple can be used for both host and device), and bound arch will make sure we get unique names. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> h) Use special options -target-offload=<triple> to specify offloading targets and delimit options meant for a toolchain.<br>
<br>
</span>I think I agree that we should generalize the flags we're using.<br>
<br>
I'm not sold on the name or structure (I'm not aware of any other flags that<br>
affect *all* flags following them?), but we can bikeshed about that separately.<br></blockquote><div><br></div><div>I guess we only have -Xblah and friends to change how the next option is used. I agree, this is issue is in many ways orthogonal to everything else in this proposal, we can address it separately.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> i) Use the offload kinds in the toolchain to drive the commands generation by Tools.<br>
<br>
</span>I'm not sure exactly what this means, but it doesn't sound<br>
particularly contentious. :)<br></blockquote><div><br></div><div>Sorry about that... My explanations get convoluted sometimes...</div><div><br></div><div>What I mean is that, instead of relying on a file input, or attributes of an action, a command can be generated by looking at the offloading kind of the toolchain.</div><div><br></div><div>E.g. </div><div><br></div><div>isCuda = isToolChainKind(Toolchain:OFFLOAD_KINDS_CUDA).</div><div><br></div><div>or</div><div><br></div><div>if(isHostToolChainKind(Toolchain:OFFLOAD_KINDS_CUDA))<br></div><div> AuxTriple = getDeviceToolChain(Toolchain:OFFLOAD_KINDS_CUDA)</div><div><br></div><div>This would allow a programming model to tune things here an there. Remember, that the same toolchain can, in general, be used by different programming models, and simultaneously by host and devices. So being able to do things based on a kind simplifies things a lot.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> 3. We are willing to help with implementation of CUDA-specific parts when<br>
> they overlap with the common infrastructure; though we expect that effort to<br>
> be driven also by other contributors specifically interested in CUDA support<br>
> that have the necessary know-how (both on CUDA itself and how it is supported<br>
> in Clang / LLVM).<br>
<br>
</span>Given that this is work that doesn't really help CUDA (the driver works fine<br>
for us as-is), I am not sure we'll be able to devote significant resources to<br>
this project. Of course we'll be available to assist with code relevant<br>
reviews and give advice.<br>
<br>
I think like any other change to clang, the responsibility will rest on the<br>
authors not to break existing functionality, at the very least inasmuch as is<br>
checked by existing unit tests.<br>
<br></blockquote><div><br></div><div>Sure, having your feedback/suggestions and help with code review is all we ask for! We will try not to break anything (and if for some reason we do will fix it right away). Also, if we find opportunities to improve the CUDA support we will be happy to contribute that as well.</div><div><br></div><div>I hope I addressed the concerns you expressed initially. Let me know any other thoughts you may have. </div><div><br></div><div>Thanks again!</div><div>Samuel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Regards,<br>
-Justin<br>
<div class=""><div class="h5"><br>
On Thu, Mar 3, 2016 at 12:03 PM, Samuel F Antao via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> Hi Chris,<br>
><br>
> I agree with Andrey when he says this should be a separate discussion.<br>
><br>
> I think that aiming at having a library that would support any possible<br>
> programming model would take a long time, as it requires a lot of consensus<br>
> namely from who is maintaining programming models already in clang (e.g.<br>
> CUDA). We should try to have something incremental.<br>
><br>
> I'm happy to discuss and know more about the design and code you would like<br>
> to contribute to this, but I think you should post it in a different thread.<br>
><br>
> Thanks,<br>
> Samuel<br>
><br>
> 2016-03-03 11:20 GMT-05:00 C Bergström <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>:<br>
>><br>
>> On Thu, Mar 3, 2016 at 10:19 PM, Ronan Keryell <<a href="mailto:ronan@keryell.fr">ronan@keryell.fr</a>> wrote:<br>
>> >>>>>> On Thu, 3 Mar 2016 18:19:43 +0700, C Bergström via cfe-dev<br>
>> >>>>>> <<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>
>> > 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>
>> > 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.<br>
>> ><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>
>><br>
>> I think may not be explaining clearly - let me elaborate by example a bit<br>
>> below<br>
>><br>
>> > In the proposal of Samuel, all the parts seem independent.<br>
>> ><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>
>> It should certainly not be science fiction or an after-thought. I<br>
>> won't go into shameless self promotion, but there are certainly useful<br>
>> things you can do when you have a "whole device kernel" perspective.<br>
>><br>
>> To digress into the liboffload component of this (sorry)<br>
>> what we have today is basically liboffload/src/all source files mucked<br>
>> together<br>
>><br>
>> What I'm proposing would look more like this<br>
>><br>
>> liboffload/src/common_middle_layer_glue # to start this may be "best<br>
>> effort"<br>
>> liboffload/src/omp # This code should exist today, but ideally should<br>
>> build on top of the middle layer<br>
>> liboffload/src/ptx # this may exist today - not sure<br>
>> liboffload/src/amd_gpu # probably doesn't exist, but<br>
>> wouldn't/shouldn't block anything<br>
>> liboffload/src/phi # may exist in some form<br>
>> liboffload/src/cuda # may exist in some form outside of the OMP work<br>
>><br>
>> The end result would be liboffload.<br>
>><br>
>> Above and below the common middle layer API are programming model or<br>
>> hardware specific. To add a new hw backend you just implement the<br>
>> things the middle layer needs. To add a new programming model you<br>
>> build on top of the common layer. I'm not trying to force<br>
>> anyone/everyone to switch to this now - I'm hoping that by being a<br>
>> squeaky wheel this isolation of design and layers is there from the<br>
>> start - even if not perfect. I think it's sloppy to not consider this<br>
>> actually. LLVM's code generation is clean and has a nice separation<br>
>> per target (for the most part) - why should the offload library have<br>
>> bad design which just needs to be refactored later. I've seen others<br>
>> in the community beat up Intel to force them to have higher quality<br>
>> code before inclusion... some of this may actually be just minor<br>
>> refactoring to come close to the target. (No pun intended)<br>
>> -------------<br>
>> If others become open to this design - I'm happy to contribute more<br>
>> tangible details on the actual middle API.<br>
>><br>
>> the objects which the driver has to deal with may and probably do<br>
>> overlap to some extent with the objects the liboffload has to load or<br>
>> deal with. Is there an API the driver can hook into to magically<br>
>> handle that or is it all per-device and 1-off..<br>
>> _______________________________________________<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>
><br>
><br>
><br>
> _______________________________________________<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>
><br>
_______________________________________________<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>