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

[Samuel F Antao via cfe-dev]

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.

Thanks!
Samuel


> […]
>
> _______________________________________________
> 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/30e76185/attachment.html>