[cfe-dev] [RFC] Unified offloading option for CUDA/HIP/OpenMP

[Artem Belevich via cfe-dev]

On Tue, Dec 15, 2020 at 10:23 AM Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Mon, Dec 14, 2020 at 14:04:43 -0800, Artem Belevich via cfe-dev wrote:
> > It all may be an utter overkill, too. WDYT?
>
> Note that tools such as ccache and sccache generally need to be able to
> understand what's going on (I believe distcc and other distributed
> compilation tools also generally need to know too), so making it
> sensible enough for interpretation based on just the flags to be
> possible should be considered.
>

I think this is somewhat orthogonal to how we specify per-target options.
Such a tool almost never knows about all possible compiler options and has
to pass through the unknown options as-is.  However, any form of 'nested'
options specified on the command line will have a chance to confuse such
tool. E.g. if I want to pass '-E' to some sub-tool for a particular
offload-target, ccache, not being aware that it's not a top-level
compilation option, may interpret it as an attempt to preprocess the TU.

I wonder if it would make sense to just move all this per-target option
complexity into an external response file. As far as existing tools are
concerned, it would look like `--offload-options=target-opts.file` without
affecting tool's general idea what this compilation is about to do, and the
external file would allow us to be as flexible as we need to be to specify
per-target options. It could be just a flat list of pairs `-Xarch_...
optA`.  Or we could use YAML.

That approach, however, has its own issues and would still need to be
optional. If it's the only way to specify offload options, that will
complicate other use cases as now they would have to deal with temporary
files.

Maybe a slightly modified variant of jdoefert@'s idea would work better:
> >>    -offload="amd -march=gfx906 -fno-vectorize" -fopenmp

Implement it in a way similar to -Wl,optA,optB,optC and extend it to match
an offload scope glob/regex.
E.g. `-offload=<offload-pattern>,optA,optB,optC`.
As far as the external tools are concerned, it's just one option to pass
though. At the same time it should be flexible enough to apply the options
to subset of offload targets in a human-manageable way.

-- 
--Artem Belevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201215/a372e963/attachment.html>