On Thu, Jun 17, 2021 at 09:28:00PM +0200, Tobias Burnus wrote:
> I am not sure whether I fully agree with this or not. However:
>
> Let's propose something radical, which probably won't break any real-world
> code, avoids the need to add a new -foffload=<something> keyword and is
> also intuitive to the user:
>
> * -foffload=<target triplet list>=-option
>
> Suggestion: This no longer affects the list of enabled targets. As by default
> all targets are enabled, this one will (kept) be(en) enabled (but might
> silently fail if the target lto1 is not installed).
>
> * -foffload=disable and -foffload=<triplet-list>
>
> This is the only way to modify the list of supported offload devices to those
> specified. By adding a triplet explicitly, it will give an error via lto1.
>
> That will solve all issues, possibly except for
> -foffload=-lm -foffload=nxpt-none=-latomic -foffload=amdgcn-amdhsa
> some might find it surprising that nvptx offloading will be disabled,
> but others might find it natural.
Could we introduce a different option which wouldn't imply enabling that
target:
-foffload-options=<target triplet list>=option
and make
-foffload=<target triplet list>=option
imply (expand in the driver)
-foffload-options=<target triplet list>=option -foffload=<target triplet list>
?
That would be mostly backwards compatible, but would allow users to specify
options
separately from the enabled target list.
The <target triplet list> in the above cases couldn't include disable or
default, but the -foffload=<target triplet list> case could, and disable
(either in the list or separately) would simply disable all targets (even
those enabled earlier), while default would reset the list to the default
(basically cancel all previous non-options -foffload= options).
And the -foffload-options= would accumulate in the order given on the
command line.
Jakub
