[PATCH] D84038: Passing the flag bigobj globally when building debug compiler on Windows
Adrian McCarthy via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 21 14:07:48 PDT 2020
amccarth added a comment.
Just a few days ago, I landed another single file /bigobj to get some LLDB tests running: https://reviews.llvm.org/rG14dde438d69c81ab4651157a94d32e5555e804ff
I did it as a single-file change in order to not perturb things more than necessary for my own use case.
I don't think there's a problem applying the change globally. I think past concerns were:
- Compatibility: Old linkers (ca 2005) couldn't read /BIGOBJ files, but those days are long behind us.
- Performance: The bug report shows the link-time impact is pretty small (about 1% for LLVM).
- Object size: Each object file would be slightly larger. I think the discussion on the bug report puts it on the order of kilobytes. That's not a lot, unless you have many, many object files.
Arguably, hitting the smaller limit could be an early warning that a file has gotten out of control (e.g., with excessive template instantiations). On the other hand, making individuals figure this out each time a file crosses the threshold has a non-zero development cost.
Applying it just to debug builds may be enough. Debug builds produce more sections. I lost the reference, but just the other day I read each externally visible symbol can result in 4 or more sections in a debug build, but only 2 or 3 in a non-debug build. So 64-ish ksections is easier to hit in a debug build.
clang-cl ignores /BIGOBJ. There are comments that it handles /bigobj "automatically," which I assume means it switches to COFF bigobj if the threshold is hit.
I don't think there's much risk to this proposal, especially if we limit to debug builds, but I'd support it for all builds if that's the consensus.
The associated bug report shows only a small impact on link time, so I don't think that's a real concern. Object file size increases are individually small, but I guess for some all of them together might add up.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D84038/new/
https://reviews.llvm.org/D84038
More information about the llvm-commits
mailing list