<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 3, 2021 at 8:46 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com">joker.eph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 3, 2021 at 1:50 PM Stella Laurenzo via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi folks, happy new year!<div><br></div><div><b>Proposal:</b></div><div><ul><li>See comments at the top of <a href="https://github.com/stellaraccident/llvm-project/blob/newcomponents/llvm/cmake/modules/LLVMComponents.cmake" target="_blank">LLVMComponents.cmake</a> in <a href="https://github.com/stellaraccident/llvm-project/tree/newcomponents" target="_blank">my fork</a>.</li><li>Draft phab: <a href="https://reviews.llvm.org/D94000" target="_blank">https://reviews.llvm.org/D94000</a></li></ul></div><div><br></div><div><b>Background:</b></div><div>As I've been working on <a href="https://github.com/llvm/mlir-npcomp" target="_blank">NPCOMP</a> trying to come up with a release flow for MLIR derived Python projects (see <a href="https://github.com/stellaraccident/mlir-py-release" target="_blank">py-mlir-release</a>), I've repeatedly run into issues with how the LLVM build system generates shared libraries. While the problems have been varied, I pattern match most of them to a certain "pragmatic" nature to how components/libLLVM/libMLIR have come to be: in my experience, you can fix most individual dynamic linkage issues with another work-around, but the need for this tends to be rooted in a lack of definition and structure to the libraries themselves, causing various kinds of problems and scenarios that don't arise if developed to stricter standards. (This isn't a knock on anyone -- I know how these things tend to grow. My main observation is that I think we have outgrown the ad-hoc nature of shared libraries in the LLVM build now).</div><div><br></div><div>I think I'm hitting this because reasonable Python projects and releases pre-supposes a robust dynamic linkage story. Also, I use Windows and am very aware that LLVM basically does not support dynamic linking on Windows -- and cannot without more structure (and in my experience, this structure would also benefit the robustness of dynamic linking on the others).</div><div><br></div><div>Several of <a href="https://llvm.discourse.group/t/meeting-notes-mlir-build-install-and-shared-libraries/2257" target="_blank">us got together to discuss this in November</a>. We generally agreed that BUILD_SHARED_LIBS was closer to what we wanted vs libLLVM/libMLIR, but the result is really only factored for development (i.e. not every add_library should result in a shared object -- the shared library surface should mirror public interface boundaries and add_library mirrors private boundaries). The primary difference between the two is:</div><div><ul><li>BUILD_SHARED_LIBS preserves the invariant that every translation unit will be "homed" in one library at link time (either .so/.dll or .a) and the system will never try to link together shared and static dependencies of the same thing (which is what libLLVM/libMLIR do today). It turns out that this is merely a good idea on most platforms but is the core requirement on native Windows (leaving out mingw, which uses some clever and dirty tricks to try to blend the worlds).</li><li>LLVM_BUILD_LLVM_DYLIB treats libLLVM.so as a "bucket" to throw things that might benefit from shared linkage, but end binaries end up also needing to link against the static libraries in case if what you want isn't in libLLVM.so. When this is done just right, it can work (on Unix) but it is very fragile and prone to multiple definition and other linkage issues that can be extremely hard to track down.</li></ul><div><b>What I did:</b></div></div><div><ol><li>Well, first, I tried looking the other way for a few months and hoping someone else would fix it :)</li><li>When I started trying to generalize some of the shared library handling for MLIR and NPCOMP, I noted that the LLVM_LINK_COMPONENTS (as in named groups of things) are in the right direction of having a structure to the libraries, and I found that I could actually rebase all of what the LLVM_LINK_COMPONENTS was trying to do on the same facility, relegating the existing LLVM_LINK_COMPONENTS to a name normalization layer on top of a more generic "LLVM Components" facility that enforces stricter layering and more control than the old libLLVM.so facility did.</li><li>I rewrote it twice to progressively more modern CMake and was able to eliminate all of the ad-hoc dependency tracking in favor of straight-forward use of INTERFACE libraries and $<TARGET_PROPERTY> generator expressions for selecting static or dynamic component trees based on global flags and the presence (or absence) of per-executable LLVM_LINK_STATIC properties</li><ol><li>Note that since this is rooted only in CMake features and not LLVM macros, out of tree, non-LLVM projects should be able to depend on LLVM components in their own targets.</li></ol><li>I hacked up AddLLVM/LLVM-Build/LLVM-Config to (mostly) use the new facility (leaving out a few things that can be fixed but aren't conceptual issues), applied a bunch of fixes to the tree that were revealed by stricter checks and got all related tests passing for LLVM and MLIR (on X86 -- some mechanical changes need to be made to other targets) for both dynamic and static builds.</li></ol><div><b>What I'd like to do:</b></div></div><div><ul><li>Get some consensus that we'd like to improve things in this area and that the approach I'm taking makes sense. I can do a lot of the work, but I don't want to waste my time, and this stuff is fragile if we keep it in an intermediate state for too long (I'm already paying this price downstream).</li><li>Land <a href="https://github.com/stellaraccident/llvm-project/blob/newcomponents/llvm/cmake/modules/LLVMComponents.cmake" target="_blank">LLVMComponents.cmake</a> as the basis of the new facility.</li><li>Finish implementing the "Redirection" feature that would allow us to emulate an aggregate libLLVM as it is today.</li><li>Start pre-staging the various stricter constraints to the build tree that will be needed to swap AddLLVM to use the new facility.</li><li>Rewrite component-related AddLLVM/LLVM-Build/LLVM-Config bits in a more principled way to use the new facility (or remove features entirely that are no longer needed) -- what I did in the above patch was just a minimal amount of working around for a POC.</li><li>Agree on whether we should try to have the two co-exist for a time or do a more clean break with the old.<br></li><li>Start applying the facility to downstream projects like MLIR and NPCOMP.</li></ul><div><b>What I would need:</b></div></div><div><ul><li>Help, testing and expertise. I am reasonably confident in my understanding of how to make shared libraries work and how to use CMake, but the legacy in LLVM here is deep -- I likely pattern matched some old features as no longer needed when they actually are (I am not clear at all on how much of LLVM-Config is still relevant).</li><li>Pointers to who the stakeholders are that I should be coordinating with.</li></ul><div>Comments?</div></div></div></blockquote><div><br></div><div>Looks great! In particular it is interesting to see how more modern CMake features could replace some of the custom-LLVM CMake macros that are likely almost a decade old now.</div><div><br></div><div>One thing I wonder about trying to see BUILD_SHARED_LIBS as some desirable for a production environment: I seem to remember that there were non-trivial performance regression when using many .so instead of a single libLLVM.so (even a single libLLVM.so was showing a measurable performance impact for clang IIRC).</div></div></div></div></blockquote><div><br></div><div>It's a good question, and one for which any hard data I can recall is hopelessly out of date. I know that back in x86 32bit days, there were non-trivial costs related to PIC and various data access indirections that were induced, but my mental model has these costs as having been very reduced/eliminated on x64 (and not a factor for others). On Windows, I know, it is very easy to end up with extra call and data access indirections unless if export/import are paired properly so that the compiler can eliminate them. </div><div><br></div><div>In the modern era, aside from fixed startup costs (which are obviously higher for shared libraries), I suspect that the biggest performance impacts will come from missed optimizations and export bloat. It is my understanding that a primary offender on that front is exporting everything with default visibility causing too many should-have-been-internal entry points to be fully materialized as black boxes and the corresponding decreased scope of any cross module optimizations. As an example, the X86 component aggregates 5 different libraries. In a BUILD_SHARED_LIBS setup, this would be 5 shared objects that expose a lot of internal symbols and potential for indirection. Since Targets are compiled with visibility=hidden, I did measure the impact of that. If IIRC, for a stripped libX86.so with visibility=hidden, the size was about 10MiB, and it was >11MiB for visibility=default. I did not measure the performance impact, but considering even just dynamic-link-time, an estimated 10% increase in the exports of one large target is going to have a measurable impact on a short lived process like clang. The finer granularity of your shared objects, the more unavoidable exported symbol bloat you are going to have (in fact, there is a special carve-out in the Targets to export everything for BUILD_SHARED_LIBS mode because it doesn't work otherwise). The coarser your shared objects, the more fixed startup overheads you will incur.</div><div><br></div><div>To be clear, what I am proposing is a facility that will let us break the shared-library granularity down to the component level, but I expect most distributions will elect some coarser granularity (up to what libLLVM.so is today). For the Python MLIR distribution, I probably want something like (Support, Core, Per-Target, and OrcJit) libraries. Aside from making for potentially smaller packages that can omit components, lazy loading some of that stands to avoid startup costs of massive shared libraries. I suspect that the sweet spot, performance wise is more fine-grained than libLLVM is today and more coarse grained than BUILD_SHARED_LIBS allows (and it will vary depending on whether the user biases towards modularity over raw size/performance).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-- </div><div>Mehdi</div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div></div>
</blockquote></div></div>