This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]