[Openmp-commits] [PATCH] D142008: [libomptarget] Delay recursive shared library registrations until offload RTLs are loaded

Mészáros Gergely via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Wed Jan 18 09:19:21 PST 2023

Maetveis added a comment.

In D142008#4062624 <https://reviews.llvm.org/D142008#4062624>, @jdoerfert wrote:

> In D142008#4062615 <https://reviews.llvm.org/D142008#4062615>, @Maetveis wrote:
>> In D142008#4062603 <https://reviews.llvm.org/D142008#4062603>, @jdoerfert wrote:
>>> This is too complex and we should not need static thread local stuff at all.
>>> Why don't we set the flag that we loaded libomptarget early. If we end up loading it again we should just not initialize it. All we really want is to reduce the scope of the lock guarding the init flag, no?
>> Yes but the problem is that we didn't finish initializing it yet when the second call comes in, we're still inside the initialization of the amdgpu plugin so that one and any others after it didn't finish initialization yet. I.e. with your proposal the inner call would skip the "second" initialization then try to register the library to partially initialized plugins.
> I don't see it. In either scheme the "inner/second" initialization of libomptarget will not actually initialize anything. You also return for the inner call and you will never come back, or how would it ever come back? Even if you do now, why would we. The second initialization is not necessary/wanted.

No I don't initialize inside the inner call, but I don't lose the library that needs to get registered (can't just simply return, also can't register that library yet), I remember it and the outermost call to `__tgt_register_lib` will after `loadRTLs` finished.

> HSA should not open libomptarget in the first place, that's just not right.

It doesn't open libomptarget, it opens a shared library that has a call to `__tgt_register_lib` in an `__attribute((constructor))` function so it gets triggered during library load. (This call is added by clang to register the shared library in case it has device code that the target runtimes need to know about)



More information about the Openmp-commits mailing list