I’m not sure I understand. tblgen itself is an executable, and that would link to the library. My understanding is that tblgen itself is an internal tool for LLVM, not distributed, so the code reuse there is less of a concern, but I don’t have an objection to making it a small CLI program around a library if that helps other projects.
The argument is that linking tblgen into LLVM is worse. It increases the size of a library that distributors want to release, including functionality that the user will not actually use in practice (especially if the tool itself is not meant to be user consumable).
Ah, then that is actually the second part of my response - that is increasing the size of a distributed library with code that is effectively dead (but cannot be eliminated because it would be part of the public interface). Making LLVMTableGen shared is perfectly reasonable, as long as it does not get compacted into LLVM as the latter is what is needed at runtime rather than build time. That is the separation that I am advocating for (isolating the build tools).
Sure, I am in favor of this, and as a matter of fact I’d love to move libSupport to the top-level of the monorepo and make it independent
LibLLVM.so would need to link to libLLVMsupport.so though, which has the drawback you mentioned in terms of performance, doesn’t it?
I think that the trade-off here is far different. Yes, we pay a small penalty, but does it outweigh the benefits? I think that tit does and actually ends up being a net win. LLVMSupport is far too commonly used, including by downstream projects and even unrelated projects due to the sheer usefulness.
LLVMTableGen is used in the LSP servers. So this is not just about build tools.
Also, there’s lots of stuff in libLLVM-*.so that is dead to a similar extent. How much use does the JIT infrastructure receive from a typical LLVM user, for example? Or the AsmParser, for that matter?
I think it makes sense to have a discussion in general about whether and how these libraries should be rearranged, but that’s a pretty complex discussion.
What I hope we can agree on more easily as a first step is that LLVMTableGen is not a special case, at least not anymore in our modern world, and therefore should not be treated like one.
Ah, this I think is a point that I had missed. This actually says that my statement was incorrect - it is used by users through the LSP.
It is used by LLDB for expression evaluation.
It is used by the integrated assembler.
I don’t think its about modernity - the use for LSPs was something that simply didn’t occur to me. However, if it is being provided for LSPs, it feels more like the job of a frontend to provide this, not the backend. Providing it through libLLVM is similar to merging libclang into libLLVM IMO.
I should have been clearer perhaps; I meant llvm/lib/AsmParser, which is (somewhat confusingly) the library for parsing textual LLVM IR. I don’t think that has any use outside of developer tools like llvm-as, opt, etc.
clang does accept LLVM IR as input - and runs differently from opt in that it uses the normal -O? pipelines. Additionally, there are some users of the LLVM bitcode as a storage format (simply stating that there are users of it).
