[menaerus]

> it doesn't seem to let you specify parallel jobs.

You don't need to if you're using the LLVM linker (lld) - by default it will use all of your HW threads (nr of cores).

    lld --help | grep thread
      --threads=<value>       Number of threads. '1' disables multi-threading. By default all available hardware threads are used

[mgaunard]

Why not just use mold?

[eru]

Mold is only available on Linux.

[mgaunard]

If you insist on using inferior OSes like Mac OS X, there is sold.

[eru]

Yes. But lots of people also have to use eg Windows.

[mgaunard]

Windows has WSL.

[BearOso]

Yes, but that CMake option also doesn't specify thin LTO, so you're only going to get 1 thread with LLVM.

[menaerus]

lld will launch as many threads by default unless it is explicitly told not to. This is with and without ThinLTO switch.

From https://clang.llvm.org/docs/ThinLTO.html#id10

  By default, the ThinLTO link step will launch as many threads in parallel as there are cores. If the number of cores can’t be computed for the architecture, then it will launch std::thread::hardware_concurrency number of threads in parallel. For machines with hyper-threading, this is the total number of virtual cores.

But maybe I misunderstood you.

[BearOso]

Yeah, regular LTO, not thin LTO, isn't currently threaded. CMake uses the former.

[menaerus]

Right. It wasn't clear at the beginning but now I understand your point. Regular LTO (by design) doesn't support concurrency nor does it support incremental builds. OTOH ThinLTO supports both.

CMake CMAKE_INTERPROCEDURAL_OPTIMIZATION variable, when set, opts in for LTO so, yes, due to LTO design you will inherently lose concurrent linkage.