[llvm-dev] (Thin)LTO llvm build

[Mehdi Amini via llvm-dev]

> On Sep 17, 2016, at 4:03 PM, Carsten Mattner <carstenmattner at gmail.com> wrote:
> 
> On Sun, Sep 18, 2016 at 12:32 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>> 
>>> On Sep 17, 2016, at 3:19 PM, Carsten Mattner <carstenmattner at gmail.com> wrote:
>>> 
>>> So, when I embark on the next ThinLTO try build, probably this Sunday,
>>> should I append -Wl,-plugin-opt,jobs=NUM_PHYS_CORES to LDFLAGS
>>> and run ninja without -j or -jNUM_PHYS_CORES?
>> 
>> 
>> ThinLTO is fairly lean on memory: It should not consume more memory per thread than if you launch the same number of clang process in parallel to process C++ files.
>> 
>> For example when linking the clang binary itself, without debug info it consumes 0.6GB with 8 threads, 0.9GB with 16 threads, and 1.4GB with 32 threads.
>> With full debug info, we still have room for improvement, right now it consumes 2.3GB with 8 threads, 3.5GB with 16 threads, and 6.5GB with 32 threads.
>> 
>> So I believe that configuring with -DDLLVM_PARALLEL_LINK_JOBS=1 should be enough without other constrains, but your mileage may vary.
> 
> Sure, I'll try that to not introduce too many variables into the
> configure changes,
> though I have to ask if using lld would make it possible to have a common -Wl
> that works across platforms, being able to ignore if it's binutils.

I’m not sure I understand the question about lld. 
Lld will be a different linker, with its own set of option.
Actually we usually rely on the clang driver to hide platform specific option and provide a common interface to the user.

> 
> If I really wanted to pass that to cmake, overriding LDFLAGS would work, right?

I don’t believe LDFLAGS is a valid cmake flag. You need to define both CMAKE_EXE_LINKER_FLAGS and CMAKE_SHARED_LINKER_FLAGS.

— 
Mehdi