On Wed, Jun 29, 2022 at 09:54:56PM +0200, Tobias Burnus wrote:
> Currently, this is a rather useless patch - even though it helps to reduce
> the number of local patches I have. Due to the printed sorry, adding a
> testcase with -fdump-tree-* is also not possible, yet.
>
> For reverse offload, the plan is to call
> GOMP_target_ext
> inside the on the device, passing
> 'device(omp_initial_device)'
> alias device(GOMP_DEVICE_HOST_FALLBACK) to the
> target device's libgomp.
>
> The pointer to the generated target-region function is then
> passed as argument. However, that only works if that function
> is not nullified ...
>
> The reason that nullifying was added is:
> https://gcc.gnu.org/PR100573
> https://gcc.gnu.org/r12-1066-g95d67762171f83277a5700b270c0d1e2756f83f4
> https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571285.html
>
>
> Note: Instead of just checking for GOMP_DEVICE_HOST_FALLBACK,
> more effort could be done, e.g. by setting some attribute on the
> generated function and then check for check for it. Example:
> 'omp target device_ancestor' + using lookup_attribute).
>
> That's what's done in the second variant.
>
> OK for mainline (which variant)? Or do you prefer to wait for
> a more complete patch?
So, what is the plan with reverse offload?
Which devices can do it? I presume we won't bother with intelmic,
can gcn do it and how, can nvptx do it and how?
What we could do is implement it initially (with all the restriction
checking etc. needed) for host fallback only, say no devices support
reverse offload and take out the sorry.
But it would be good to at least have some idea how it will be implemented
for some offloading devices, whether map will there anything at all (or it
will require unified shared memory) and how we'll map the fn argument passed
to GOMP_target_ext back to the host function address.
Jakub
