================ @@ -1233,6 +1233,10 @@ def offload_compression_level_EQ : Joined<["--"], "offload-compression-level=">, Flags<[HelpHidden]>, HelpText<"Compression level for offload device binaries (HIP only)">; +def offload_jobs_EQ : Joined<["--"], "offload-jobs=">, + HelpText<"Set the number of threads for the clang-linker-wrapper. Defaults to" + " half of the available hardware threads if not specified.">; ---------------- Artem-B wrote:
> This seems like it would interact poorly with parallel build systems. +1 to that. Build scaling should be left to the build maintainers. Compiler just does not have all the necessary information to make a good decision. It's easy to come up with a scenario that benefit a single developer running compilation manually or doing a local build, but things don't work that well for the large scale builds, where the single-user/single-machine assumptions no longer hold true. The default assumptions of pretty much all build systems out there are that one compilation -> 1 CPU, and changing it may have more undesired impact than intended. E.g. it's not uncommon for multiple link jobs to be launched nearly simultaneously, after some common dependency library has finished building. Each of N linking jobs on an N-CPU machine trying to grab N/2 CPUs will not end well, and is likely to be slower than running those jobs in sequential mode. https://github.com/llvm/llvm-project/pull/135229 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
