This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Nathan Sidwell <nathan at codesourcery dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Tue, 20 Oct 2015 13:45:37 +0200
- Subject: Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1509111318520 dot 11676 at digraph dot polyomino dot org dot uk> <55F2E935 dot 7010300 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1509111525030 dot 11676 at digraph dot polyomino dot org dot uk> <87egjopgh0 dot fsf at kepler dot schwinge dot homeip dot net> <20150911154349 dot GH1847 at tucnak dot redhat dot com> <87a8s6vq69 dot fsf at kepler dot schwinge dot homeip dot net> <20150929081814 dot GD1847 at tucnak dot redhat dot com> <5624F236 dot 9020308 at mentor dot com> <87lhbnsy1s dot fsf at kepler dot schwinge dot homeip dot net> <87mvve95af dot fsf at schwinge dot name> <20151020100245 dot GW478 at tucnak dot redhat dot com> <87bnbt94bq dot fsf at schwinge dot name>
On 10/20/2015 01:17 PM, Thomas Schwinge wrote:
As explained a few times already: GOMP_offload_register_ver constructors
will only be generated if there actually are offloaded code regions, but
for example:
#include <openacc.h>
int main()
{
__builtin_printf("%d\n", acc_get_num_devices(acc_device_nvidia));
return 0;
}
... is a valid OpenACC program (untested), which doesn't contain any
offloaded code regions. As a user I'd expect it to return different
answers if compiled with -foffload=nvptx-none in contrast to
-foffload=disable. Actually, I can foresee exactly such code to be used
to probe for offloading being available, for example in testsuites. And,
I guess we agree that under -foffload=disable we'd like the
compilation/runtime system to be configured in a way that no offloading
will happen?
Both of you can ignore me if you feel I'm not making sense, but what
exactly is the use case for -foffload=disable? Isn't it slightly
redundant with -fno-openacc? IMO it's not an option that alters the
available devices, that's a question that is answered at run-time and
doesn't (or shouldn't) really depend on compiler switches. As a user I'd
expect -foffload=disable to just prevent generation of offloaded code
for the things I'm compiling. As Jakub pointed out, shared libraries may
still contain other pieces that are offloadable.
I guess I don't fully understand why you want to go to great lengths to
disable devices at run-time based on a compile-time switch. What's the
reasoning here?
Nathan has used this term before (libgomp/openacc.h:acc_device_t), and he
told me this means "High Water Mark". I have no strong opinion on the
name to use, just want to mention that "*_LAST" sounds to me like that
one still is part of the accepted set, whereas in this case it'd be the
first enumerator outside of the accepted ones. (And I guess, we agree
that "OFFLOAD_TARGET_TYPE_INTEL_LAST = 6" followed by
"OFFLOAD_TARGET_TYPE_INTEL_MIC = OFFLOAD_TARGET_TYPE_INTEL_LAST" is
ugly?)
Nah, just rename HWM to LAST, that's fairly common usage I think.
Bernd