We should introduce aspects for differentiating native and offload devices

[AerialMantis]

When trying to define the __SYCL_DEVICE_ONLY__ macro in terms of how a user would use it I came across a gap in the current SYCL 2020 specification. The gap is that since the removal of the explicit host device and introduction of the emulated and host_debuggable aspects to replace it, there is currently no way for users to distinguish whether a device executes native code, i.e. as-if compiled by a non-SYCL C++ compiler, or offload code, i.e. code which has been offloaded to another architecture such as SPIR-V, NVPTX or AMDGCN by a SYCL compiler.

When we introduced host_debuggable the intention was that this would be able to infer that the device executes native code, however, this doesn't necessarily need to be the case, it's possible for a SYCL device to execute offload code and still support debuggers.

Therefore I propose we introduce new device aspects which can be used to query whether a device executes native or offload code; aspect::native and aspect::offload.

This would provide a few benefits. Firstly it would provide a mechanism for users to query whether a device will execute native or offload code, i.e. execute or not execute code pre-processed with __SYCL_DEVICE_ONLY__. A second benefit of this would be that if a SYCL implementation is that the __SYCL_DEVICE_ONLY__ macro cannot be used to differentiate between native and offload code execution in the case of a single pass SYCL device compiler, where as aspects would be able to.

Finally these aspects would provide an additional dimension to the device capability hierarchy, which would help differentiate the different kind of SYCL devices across the various SYCL implementations, including host devices and various kinds of library only devices.

One important thing to consider here is that these aspects could be encountered in function reachable from a SYCL kernel or a SYCL_DEVICE decorated function in the call graph, i.e. from a parallel_for (executing either native or offload code), or unreachable, i.e. outside of a SYCL kernel, and it's not possible for the implementation of these new aspects to distinguish between these two cases. However, this does not need to be a problem, the user would just need to be aware that if the aspect is encountered in control flow outside of a SYCL kernel, aspect::native would always be true.