User Details
- User Since
- Aug 8 2018, 9:28 PM (251 w, 2 d)
Nov 28 2022
Overall this approach looks good to me, though I'd suggest some (hopefully minor) changes that would help avoid breaking the ABI. It looks like __tgt_bin_desc is only used by __tgt_[un]register_lib -- rather than changing those entry points, can you please add new ones (e.g., __tgt_[un]register_lib_v2 or __tgt[un]register_lib_with_requires)? You can still remove the old entry points from libomptarget. This should avoid any ABI issues with the old entry points, since calls to the old entry points will expect the old struct and calls to the new entry points will expect the new struct. This will also make it possible for vendors to continue supporting the old entry points, if desired.
Jan 21 2022
I don't see a clear explain the motivation for this change - can you confirm my understanding or provide clarification? It looks like the issue is that D110337 caused a regression for cases when user code directly calls a device library function that requires hostcall services, right? If so, I think this issue highlights a weakness in the module flag approach implemented in D110337 - i.e., now the compiler needs to know every library function that may require hostcall services.