[llvm-dev] debug build busts memory

[Reid Kleckner via llvm-dev]

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/0a28da05/attachment.html>