[Bug 281765] llvm - ThinLTO never uses more than a single thread by default

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281765

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #1 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
From a vintage of main's [so: 15's] contrib/llvm-project/lld/ELF/Driver.cpp

QUOTE
 // --threads= takes a positive integer and provides the default value for
  // --thinlto-jobs=. If unspecified, cap the number of threads since
  // overhead outweighs optimization for used parallel algorithms for the
  // non-LTO parts.
  if (auto *arg = args.getLastArg(OPT_threads)) {
    StringRef v(arg->getValue());
    unsigned threads = 0;
    if (!llvm::to_integer(v, threads, 0) || threads == 0)
      error(arg->getSpelling() + ": expected a positive integer, but got '" +
            arg->getValue() + "'");
    parallel::strategy = hardware_concurrency(threads);
    config->thinLTOJobs = v;
  } else if (parallel::strategy.compute_thread_count() > 16) {
    log("set maximum concurrency to 16, specify --threads= to change");
    parallel::strategy = hardware_concurrency(16);
  }
  if (auto *arg = args.getLastArg(OPT_thinlto_jobs_eq))
    config->thinLTOJobs = arg->getValue();
  config->threadCount = parallel::strategy.compute_thread_count();
END QUOTE

The code is mostly a mix of:

Vendor import of llvm-project master 2e10b7a39b9, the last commit
beforevendor/llvm-project/llvmorg-11-init-20887-g2e10b7a39b9vendor/llvm-project/master
the llvmorg-12-init tag, from which release/11.x was branched.

and:

Vendor import of llvm-project main
llvmorg-17-init-19304-gd0b54bb50e51,vendor/llvm-project/llvmorg-17-init-19304-gd0b54bb50e51
the last commit before the upstream release/17.x branch was created.

The web pages have not been updated to give all the details as
things have changed.

I'll also note that poudriere bulk runs with multiple builders
could try to run multiple of these in overlapping time frames
and so get a total number of being a multiple of the physical
core count. Setting -Wl,--thinlto-jobs=N across such in order
to get the total at the system level controlled is not a
trivial problem. poudriere bulk use need not be the only type
of context with such issues or to compete for FreeBSD cpus in
ways that go well beyond the physical cpu count.

-- 
You are receiving this mail because:
You are the assignee for the bug.