I agree with you in principle, and the problem here is specifically with LLVM (considering the libraries that TVM uses). It’s a consequence of the evolution of LLVM, and of its use cases, something that likely does not apply to other libraries to the same extent.
I’m pretty sure that LLVM would be interested in a solution to the reconfiguration problem. The issue is that it would take a while to both design an appropriate solution, and to implement it. At the earliest, the fix would go in LLVM 15.0.0, and since TVM supports LLVM 4+, it means that we’d still have to deal with this problem for a very long time.
The dlopen/dlclose solution has the benefit of being clean—we start with a clean slate, and do not leave any “leftovers” behind. If we treat the global state issue in LLVM is a “feature”, then the best practice would be to implement it in a way that completely avoids it. At the same time, with the ability to modify command-line options in-place, the importance of that is greatly diminished, to the point where, I’d agree that it’s no longer needed.
I think that the current plan (i.e. access the option registry directly) is sufficient to accomplish our goals, but I’m open to further arguments. It doesn’t actually affect the need to “localize” LLVM configuration, so it’s more of an implementation detail rather than the basis of the plan.