https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114690
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
With commit r16-3925-gda5803c794d16deb461c93588461856fbf6e54ac
libgomp: Init hash table for 'indirect'-clause of 'declare target' on the
host [PR114445, PR119857]
the implementation has changed, but to-do items remain.
STATUS: Since that commit, for newer code the hash is created on the host and
copied to the device – in the plugin-{nvptx,gcn}.c. Thus, the main usage case
is handled.
However, the following needs to be checked/addressed - aka -
TODO:
* How should be multiple kernels handled if more than one has an indirect
table?
* What needs to be done when an image is unloaded?
* The hash-table on the host should be freed, unless it is needed until the end
of the program - especially, if the status does not need to be traced on the
host.
I have to admit that it is not completely clear to me what happens when
multiple kernels are loaded - each containing a statically linked libgomp.a.
Will there be one consolidated __gomp_indirect_addr_hmap per device or will
there be one per loaded kernel image?
The current kernel-unload code runs destructors but otherwise does not clean up
any memory, implying that all associated memory will automatically be freed on
unloading?
GOAL:
- Avoid slow pointless walking of data structures in the common case to avoid
slowness at the end of the program (and the like),
- but still handle more special cases like multi-images w/ indirect correctly.
