[PATCH] D130121: [3/3] [COFF] Emit embedded -exclude-symbols: directives for hidden visibility for MinGW

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 10 04:19:34 PDT 2022


mstorsjo added a comment.

In D130121#3710836 <https://reviews.llvm.org/D130121#3710836>, @mstorsjo wrote:

> In D130121#3710488 <https://reviews.llvm.org/D130121#3710488>, @rnk wrote:
>
>> One major reservation that I have about this solution is that we've discovered that the .drective section is extremely inefficient.
>
> I can try to do a test build of LLVM with and without this feature (with a separate patch that takes the hidden visibility into use) and see how much it inflates the build directory. What would be the best measuring point for that? Maybe the size of the largest object file and/or largest static library?

Ok, now I've tested actually measuring this and comparing the tradeoff. I've tested building llvm+clang with `-DLLVM_LINK_LLVM_DYLIB=TRUE`, with a patch to take the hidden visibility into use.

- Individual object files do grow - undoubtedly. One large object file is `tools/clang/lib/ASTMatchers/Dynamic/CMakeFiles/obj.clangDynamicASTMatchers.dir/Registry.cpp.obj`, which grew from 4.2 MB to 4.6 MB. (And to doublecheck things; this object file now has a `.drectve` section at 409 KB.) I.e. this grew by around 10%.

- The total build directory actually ended up slightly smaller (but by a very small margin); originally it was 1234 MB, now it is 1232 MB. One factor here is that since we're exporting much fewer symbols (and possibly due to better codegen due to knowing about hidden visibility?), some files shrink - a notable amount. `libLLVM-16.git.dll` ends up at 58.9 MB where it originally was 62.3 MB. The import library, `libLLVM-16git.dll.a`, is now 12 MB instead of 24 MB.

- Linking time with lld changes negligibly. Linking `libLLVM-16git.dll` takes somewhere around 1.0-1.4 seconds on the system I'm testing, and the change is much much smaller than my measurement noise here.

- Linking time with binutils changes a lot though. The implementation I made in ld.bfd used the same naive data structure used for e.g. `aligncomm` directives (a linked list of strings, so just inserting strings into it ends up as O(n^2)), so this ends up quite inefficient. Previously, linking libLLVM-16git.dll took 28 seconds, now it takes 66 seconds. But that's something that could be improved on the binutils side, not a limitation of the format itself per se.

All in all, it doesn't look too bad to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130121



More information about the llvm-commits mailing list