[llvm-dev] debug build busts memory

[Keane, Erich via llvm-dev]

  *   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 perfectly OK with that.  I only compile debug, so having my normal set of build flags be unnecessary would be wonderful.  In addition to the two below, I only add -G “Ninja” (plus ‘LLVM_ENABLE_PROJECTS=…

From: Reid Kleckner <rnk at google.com>
Sent: Tuesday, November 26, 2019 11:04 AM
To: Keane, Erich <erich.keane at intel.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] debug build busts memory

On Tue, Nov 26, 2019 at 10:46 AM Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org<mailto: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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/c256008b/attachment.html>