[Openmp-commits] [PATCH] D131011: [Libomptarget] Deinitialize AMDGPU global state more intentionally

[Joseph Huber via Phabricator via Openmp-commits]

jhuber6 updated this revision to Diff 449434.
jhuber6 added a comment.

Trying to clean up.

That being said, I've been doing some more thinking about how to handle this and  I don't think this is the right way to go. We can set an explicit order on the destruction of the plugins, but that doesn't necessarily mean that the memory or libraries depending on that plugin will still be valid. I think this is the core issue behind why I was seeing weird behaviour porting CUDA to this method. For the CUDA RTL, the CUDA library may already be unloaded by the time we try to uninititalize the data and i don't think there's any way to guaruntee this one way or the other.

I'm thinking one reasonable way to solve this is to instead handle device destructors via `atexit()`, I believe that function is supposed to be called before standard user exit, e.g. after main() and exit(). That would allow us to run those functions before the destructors start unwinding presumably. Then to solve the problem that Jon's original patch aimed to solve, we simply make accessing internal plugin state illegal and explicitly `dlclose` the plugin at the start to prevent this. For this we would need to then remove the `is_valid_binary_info` calls, this should be easily replaced with some data structure that saves them instead of trying to derive them all over again. There may be some problems with this approach as well, but we really need an intelligent way to handle this stuff that won't blow up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131011/new/

https://reviews.llvm.org/D131011

Files:
  openmp/libomptarget/plugins/amdgpu/src/rtl.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D131011.449434.patch
Type: text/x-patch
Size: 6049 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20220802/9ca13ebb/attachment.bin>