[cfe-dev] [RFC][OpenMP][CUDA] Unified Offloading Support in Clang Driver

Thu Feb 25 12:51:51 PST 2016

Hi Jonas,

2016-02-25 15:39 GMT-05:00 Hahnfeld, Jonas via cfe-dev <
cfe-dev at lists.llvm.org>:

> Hi Samuel,
>
>
>
> *From:* samuelfantao at gmail.com [mailto:samuelfantao at gmail.com] *On Behalf
> Of *Samuel F Antao
> *Sent:* Thursday, February 25, 2016 8:55 PM
> *To:* Hahnfeld, Jonas
> *Cc:* Samuel F Antao; cfe-dev at lists.llvm.org; Alexey Bataev; John McCall
> *Subject:* Re: [cfe-dev] [RFC][OpenMP][CUDA] Unified Offloading Support
> in Clang Driver
>
>
>
> Hi Jonas,
>
>
>
>
>
>
>
> 2016-02-25 10:51 GMT-05:00 Hahnfeld, Jonas via cfe-dev <
> cfe-dev at lists.llvm.org>:
>
> Hi Samuel,
>
>
>
> Thanks for your work, I would really much like to see OpenMP offloading
> implemented in clang!
>
> I can’t judge the necessary changes to the driver infrastructure but will
> rather focus on an end-user view…
>
>
>
> *From:* samuelfantao at gmail.com [mailto:samuelfantao at gmail.com] *On Behalf
> Of *Samuel F Antao
> *Sent:* Thursday, February 25, 2016 1:02 AM
> *To:* cfe-dev at lists.llvm.org
> *Cc:* Alexey Bataev; Hal Finkel; John McCall; echristo at gmail.com;
> tra at google.com; Hahnfeld, Jonas
> *Subject:* [RFC][OpenMP][CUDA] Unified Offloading Support in Clang Driver
>
>
>
> […]
>
> g) Reflect the offloading programming model in the naming of the
> save-temps files.
>
> Given that the same action is interpreted by different toolchains, if
> using save-temps the resulting file could be append with the programming
> model name by the target triple so that files don’t get overwritten.
>
>
>
> E.g. for OpenMP one would get a.bc and a-openmp-<triple>.bc if the driver
> is invoked with 'clang -c -save-temps a.c’.
>
> So these temporary files would all be unbundled so that they can be worked
> with as before? Or do you intend to save the bundled file as well?
> a-openmp-<triple>.bc might get you into troubles if you are using the same
> triple for host and device…
>
>
>
> All the intermediate files would be saved as today, only with the extra
> suffix to avoid conflicts. The bundled file is the output requested by the
> user so it would be saved regardless of the save-temps option.
>
>
>
> You are right, we should also use "host" and "device" to avoid problems
> when the same triple is used. I think I was proposing that already in
> D9888, just forgot to mention it here. Sorry about that.
>
>
>
>
>
> h) Use special options -target-offload=<triple> to specify offloading
> targets and delimit options meant for a toolchain.
>
> To avoid the proliferation of driver (and possibly frontend) options that
> are specific for a programming model I propose a new option that would
> specify an offloading device and have all the options following it
> processed for its toolchain. This would allow using the already existing
> options like -mcpu or -L/-l to tune the implementation for a given machine
> or provide linking commands that only make sense for the device.
>
>
>
> As an hypothetical example, lets assume we wanted to compile code that
> uses both CUDA for a nvptx64 device, OpenMP for an x86_64 device, and a
> powerpc64le host, one could invoke the driver as:
>
>
>
> clang -target powerpc64le-ibm-linux-gnu <more host options>
>
> -target-offload=nvptx64-nvidia-cuda -fcuda -mcpu sm_35 <more options for
> the nvptx toolchain>
>
> -target-offload=x86_64-pc-linux-gnu -fopenmp <more options for the x86_64
> toolchain>
>
> -target-offload=host <more options for the host>
>
> -target-offload=all <options for all toolchains>
>
>
>
> -fcuda or -fopenmp (or any other flag specifying a programming model)
> associated with an offload target would specify the programming model to be
> used for that target, and an error would be emitted if no programming model
> flag is found. I am also proposing having as special target-offload devices
> “host” and “all” to provide a convenient way for the user to pass options
> for all toolchains or to the host.
>
> Would you have to specify ‘-fopenmp’ twice if you want to use OpenMP on
> the host as well? I’m asking because I’m interpreting your proposal that
> ‘-target-offload’ consumes all following options only for this specific
> target…
>
>
>
> Yes. However I'm open to have a behavior that infers it based on the host
> options or input files (like *.cu in CUDA). However, if two different
> programming models are used in the same compilation unit, it has to be
> explicitly specified.
>
>
>
> That’s true. I’m fine about specifying it explicitly in the first
> implementation, maybe we can later on think about some “magic guessing” if
> only one model is provided.
>

Yes. I'd also like to hear the feedback of the CUDA developers about this
to understand what are they users' expectations. I think that one probably
wants to at least do an initial guess for the CUDA file extensions.

Thanks,
Samuel

>
>
> Thanks,
>
> Jonas
>
>
>
>
>
> Thanks!
>
> Samuel
>
>
>
> […]
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
> _______________________________________________
> 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/20160225/f8cb75f8/attachment.html>