[llvm-dev] debug build busts memory
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 26 11:03:30 PST 2019
On Tue, Nov 26, 2019 at 10:46 AM Keane, Erich via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I believe it is pretty clear that the stock ld linker is basically
> unusable for our project without a sizable amount of hardware. I’ve
> typically found that using gold or lld fixes this problem entirely.
> Perhaps we need to start having CMake detect the presence of lld and use
> that if possible, else check for ‘gold’ and use it if possible, and only
> THEN fall back on ld.
+1, we should probably emit a warning if we have to fall back to ld.bfd.
It's basically non-functional for large C++ apps.
> Additionally, it is pretty rare for someone to need to debug TableGen (at
> least in my experience), and if they DO need it, they would know enough to
> know how to change the cmake variable. I think we should have a serious
> discussion about making LLVM_OPTIMIZED_TABLEGEN=true be default.
If you are doing a release build already (my workflow), this represents a
lot of additional overhead: second cmake config step, separate ninja
subbuild. But if you are doing a debug build, it's clearly better, and
there is no easy alternative. What do you think about enabling it for
multi-config generators and single-config debug builds, so single-config
release builds are not affected? I'd be in favor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev