> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org <mailto:phosek at chromium.org>>: > You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the number of link jobs.IMO, a more thorough solution would be switching to LLD (the gold linker might work few years ago, but now even gold will take me nearly 16GB of RAM), usually LLD won’t take you more than 4GB -Min> > On Sat, Aug 8, 2020 at 3:00 PM Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > https://ninja-build.org/manual.html <https://ninja-build.org/manual.html> > ninja -h prints help output. Many of Ninja’s flags intentionally match those of Make; e.g ninja -C build -j 20 changes into the build directory and runs 20 build commands in parallel. > > Neil Nelson > > On 8/8/20 3:41 PM, David Blaikie via llvm-dev wrote: >> On Sat, Aug 8, 2020 at 2:22 PM Dmitry Mikushin via llvm-dev >> <llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org> wrote: >>> Ninja is really good, indeed. The only problem I've seen is that LLVM linking step (made massively parallel by Ninja) renders the 8GB RAM system unresponsive due to excessive swapping. >> FWIW, there is a way to limit the number of parallel link jobs in >> particular (so compile jobs can still have more parallelism). I don't >> recall exactly what it is - I guess some CMake variable. >> >>> You can reconfigure CMake to use Ninja in an existing build folder, but it will not use the binaries previously built with another tool. Moreover, generated files may clash in an incompatible way, so it's rather better to cleanup the old build. >>> >>> Kind regards, >>> - Dmitry. >>> >>> сб, 8 авг. 2020 г. в 23:12, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> <mailto:llvm-dev at lists.llvm.org>: >>>> I built my first submission with Visual Studio, but everything I read and watch suggests Ninja, about which I know nothing. Is it okay if I rerun CMake with -G "Ninja" in the same build directory, then just run ninja? >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200808/b35863d6/attachment.html>
Hm, I think this should already be lld, as long as this is on Mac with a "stock" clang toolchain. вс, 9 авг. 2020 г. в 01:02, Min-Yih Hsu <minyihh at uci.edu>:> > > On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Cool, thanks! > > вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org>: > >> You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the >> number of link jobs. >> > IMO, a more thorough solution would be switching to LLD (the gold linker > might work few years ago, but now even gold will take me nearly 16GB of > RAM), usually LLD won’t take you more than 4GB > > -Min > > >> On Sat, Aug 8, 2020 at 3:00 PM Neil Nelson via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> https://ninja-build.org/manual.html >>> >>> ninja -h prints help output. Many of Ninja’s flags intentionally match >>> those of Make; e.g ninja -C build -j 20 changes into the build >>> directory and runs 20 build commands in parallel. >>> >>> Neil Nelson >>> On 8/8/20 3:41 PM, David Blaikie via llvm-dev wrote: >>> >>> On Sat, Aug 8, 2020 at 2:22 PM Dmitry Mikushin via llvm-dev<llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org> wrote: >>> >>> Ninja is really good, indeed. The only problem I've seen is that LLVM linking step (made massively parallel by Ninja) renders the 8GB RAM system unresponsive due to excessive swapping. >>> >>> FWIW, there is a way to limit the number of parallel link jobs in >>> particular (so compile jobs can still have more parallelism). I don't >>> recall exactly what it is - I guess some CMake variable. >>> >>> >>> You can reconfigure CMake to use Ninja in an existing build folder, but it will not use the binaries previously built with another tool. Moreover, generated files may clash in an incompatible way, so it's rather better to cleanup the old build. >>> >>> Kind regards, >>> - Dmitry. >>> >>> сб, 8 авг. 2020 г. в 23:12, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>: >>> >>> I built my first submission with Visual Studio, but everything I read and watch suggests Ninja, about which I know nothing. Is it okay if I rerun CMake with -G "Ninja" in the same build directory, then just run ninja? >>> >>> _______________________________________________ >>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200809/1a05c6a0/attachment-0001.html>
lld does not support Mac system really, on a Mac you're using the Apple Linker ld64. In general though with 8 GB you likely want to limit your build to 4 threads (ninja -j 4) anyway. -- Mehdi On Sat, Aug 8, 2020 at 4:35 PM Dmitry Mikushin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hm, I think this should already be lld, as long as this is on Mac with a > "stock" clang toolchain. > > вс, 9 авг. 2020 г. в 01:02, Min-Yih Hsu <minyihh at uci.edu>: > >> >> >> On Aug 8, 2020, at 3:32 PM, Dmitry Mikushin via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Cool, thanks! >> >> вс, 9 авг. 2020 г. в 00:27, Petr Hosek <phosek at chromium.org>: >> >>> You can set the LLVM_PARALLEL_LINK_JOBS CMake variable to restrict the >>> number of link jobs. >>> >> IMO, a more thorough solution would be switching to LLD (the gold linker >> might work few years ago, but now even gold will take me nearly 16GB of >> RAM), usually LLD won’t take you more than 4GB >> >> -Min >> >> >>> On Sat, Aug 8, 2020 at 3:00 PM Neil Nelson via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> https://ninja-build.org/manual.html >>>> >>>> ninja -h prints help output. Many of Ninja’s flags intentionally match >>>> those of Make; e.g ninja -C build -j 20 changes into the build >>>> directory and runs 20 build commands in parallel. >>>> >>>> Neil Nelson >>>> On 8/8/20 3:41 PM, David Blaikie via llvm-dev wrote: >>>> >>>> On Sat, Aug 8, 2020 at 2:22 PM Dmitry Mikushin via llvm-dev<llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org> wrote: >>>> >>>> Ninja is really good, indeed. The only problem I've seen is that LLVM linking step (made massively parallel by Ninja) renders the 8GB RAM system unresponsive due to excessive swapping. >>>> >>>> FWIW, there is a way to limit the number of parallel link jobs in >>>> particular (so compile jobs can still have more parallelism). I don't >>>> recall exactly what it is - I guess some CMake variable. >>>> >>>> >>>> You can reconfigure CMake to use Ninja in an existing build folder, but it will not use the binaries previously built with another tool. Moreover, generated files may clash in an incompatible way, so it's rather better to cleanup the old build. >>>> >>>> Kind regards, >>>> - Dmitry. >>>> >>>> сб, 8 авг. 2020 г. в 23:12, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org>: >>>> >>>> I built my first submission with Visual Studio, but everything I read and watch suggests Ninja, about which I know nothing. Is it okay if I rerun CMake with -G "Ninja" in the same build directory, then just run ninja? >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200808/a984b45a/attachment.html>