Hi,
Thomas Schwinge wrote:
An issue with libgomp GCN plugin 'GCN_SUPPRESS_HOST_FALLBACK' (which is
different from the libgomp-level host-fallback execution):
+failure:
+ if (suppress_host_fallback)
+ GOMP_PLUGIN_fatal ("GCN host fallback has been suppressed");
+ GCN_WARNING ("GCN target cannot be launched, doing a host fallback\n");
+ return false;
+}
This originates in the libgomp HSA plugin, where the idea was -- in my
understanding -- that you wouldn't have device code available for all
'fn_ptr's, and in that case transparently (shared-memory system!) do
host-fallback execution. Or, with 'GCN_SUPPRESS_HOST_FALLBACK' set,
you'd get those diagnosed.
This has then been copied into the libgomp GCN plugin (see above).
However, is it really still applicable there; don't we assume that we're
generating device code for all relevant functions? (I suppose everyone
really is testing with 'GCN_SUPPRESS_HOST_FALLBACK' set?)
First, I think most users do not set GCN_SUPPRESS_HOST_FALLBACK – and it
is also not really desirable.
If I run on my Linux system the system compiler with nvptx + gcn suppost
installed, I get (with a nvptx permission problem):
$ GCN_SUPPRESS_HOST_FALLBACK=1 ./a.out
libgomp: GCN host fallback has been suppressed
And exit code = 1. The same result with '-foffload=disable' or with
'-foffload=nvptx-none'.
Should we thus
actually remove 'suppress_host_fallback' (that is, make it
always-'true'),
If we want to remove it, we can make it always false - but I am strongly
against making it always true.
Use OMP_TARGET_OFFLOAD=mandatory (or that GCN env) if you want to
prevent the host fallback, but don't break somewhat common systems.
Tobias
