# Modularizing LLVM codegen/JIT

**URL:** <https://discuss.tvm.apache.org/t/modularizing-llvm-codegen-jit/12764>\
**Category:** RFC\
**Created:** [May 13, 2022, 6:42pm UTC](https://discuss.tvm.apache.org/t/modularizing-llvm-codegen-jit/12764 "2022-05-13T18:42:47Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![kparzysz](https://discuss.tvm.apache.org/user_avatar/discuss.tvm.apache.org/kparzysz/32/252_2.png) [@kparzysz](https://discuss.tvm.apache.org/u/kparzysz)\
**Post date:** [May 13, 2022, 7:57pm UTC](https://discuss.tvm.apache.org/t/modularizing-llvm-codegen-jit/12764/9 "2022-05-13T19:57:41Z")

</div>

Cold you elaborate on the need for static linking? Is this something that Windows requires in every situation, or is it specific to PyTorch? Do you know how to reproduce this problem?

I think it will be easier to find solutions to such issues than it would be to reset LLVM state. LLVM uses a lot of global variables (often static), and relies on static constructors to do some work…

Edit:

If I understand correctly, PyTorch has some LLVM library code linked into it as well. The plan would not expose LLVM functions outside of the shared library. All LLVM symbols can be local to it, and not visible outside. The shared library would have functions like `runtime::Module compile(IRModule)`. That should avoid conflicts with other definitions of LLVM symbols coming from elsewhere.

---

_[View the full topic](https://discuss.tvm.apache.org/t/modularizing-llvm-codegen-jit/12764)._