search for: kitayama

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tom Stellard > via llvm-dev > Sent: Wednesday, April 1, 2020 7:49 PM > To: Itaru Kitayama <itaru.kitayama at gmail.com> > Cc: Nemanja Ivanovic via llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] LLD issue on a massively parallel build machine > > On 04/01/2020 04:12 PM, Itaru Kitayama wrote: > > On another login node which is 256 (GB)/48 (n...

On Thu, Apr 2, 2020 at 11:35 AM Itaru Kitayama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Setting LLVM_PARALLEL_LINK_JOBS > did not help a week or two weeks ago’s lld. > > But recent commits to lld might reflect the variable correctly. > FYI: the variable has nothing to do with lld itself (not commits to lld woul...

...mention in the bug that it's > specifically LIBOMPTARGET_ENABLE_DEBUG that is slowing down your > compilation time? Not the use of a Debug build of LLVM? Have you tried a > Release build of LLVM but with LIBOMPTARGET_ENABLE_DEBUG enabled? > > On Fri, Jan 3, 2020 at 11:58 AM Itaru Kitayama <itaru.kitayama at gmail.com> > wrote: > >> At least, to obtain enough information from libomptarget while running my >> offloading app on GPU capable environment, I have to build it with an LLVM >> which was built in Debug mode. >> >> On Sat, Jan 4, 2020 a...

Yes, exactly. On Sun, Jan 5, 2020 at 23:43 Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Fri, Jan 3, 2020 at 8:58 PM Itaru Kitayama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I have just tried a Release build of LLVM but >> with >> LIBOMPTARGET_ENABLE_DEBUG enabled. The app build became super fast, but I >> can not obtain debugging information that I need at runtime. >> &g...

On another login node which is 256 (GB)/48 (nodes) JURECA at JSC, I never had an LLD issue without setting -j when executing ninja in the past few weeks. On Thu, Apr 2, 2020 at 7:17 AM Itaru Kitayama <itaru.kitayama at gmail.com> wrote: > Tom, > Then what ratio do you think it’s minimal? > > On Thu, Apr 2, 2020 at 6:11 Tom Stellard <tstellar at redhat.com> wrote: > >> On 04/01/2020 01:47 PM, Itaru Kitayama via llvm-dev wrote: >> > Thanks for the heads...

...btain enough information from libomptarget while running my offloading app on GPU capable environment, I have to build it with an LLVM which was built in Debug mode. On Sat, Jan 4, 2020 at 4:34 David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jan 2, 2020 at 10:55 PM Itaru Kitayama <itaru.kitayama at gmail.com> > wrote: > >> As I am facing the serious super slow down: >> https://bugs.llvm.org/show_bug.cgi?id=44407 , I'd like to >> learn more about how it can be minimized. When debugging an app, there >> are times building it with a >...

...ng an app, there are times building it with a Debug build LLVM can not be avoided, but a situation like 40 times time increase (40 minutes) is hard to work with. On Fri, Jan 3, 2020 at 11:14 AM David Blaikie <dblaikie at gmail.com> wrote: > > > On Thu, Jan 2, 2020 at 6:09 PM Itaru Kitayama <itaru.kitayama at gmail.com> > wrote: > >> David, >> Yes, I was indeed trying to build LLVM with a Debug build. I'll stop >> doing that from now on. >> > > I mean, you can - it's just going to be super slow & mostly not what you > want, unle...

On 04/01/2020 01:47 PM, Itaru Kitayama via llvm-dev wrote: > Thanks for the heads up the supercomputer > Is down for maintenance this week. > I’ll give it a try when it gets back. > This doesn't look to me like it's necessarily an lld issue. Trying to build all the sub-projects without limiting the number of ninj...

...threads. https://reviews.llvm.org/D76885 (committed yesterday) changed --no-threads to --threads={1,2,...} (--no-threads is used rarely (GNU ld does not support it) so I'd rather not keep the option for compatibility). You may try -Wl,--threads=1 >On Sat., Mar. 28, 2020, 4:19 p.m. Itaru Kitayama, <itaru.kitayama at gmail.com> >wrote: > >> Good news, I was able to use up to 37 cores for LLVM build with LLD. >> The build speed, did not measure precisely though, is comparable to the >> build with GNU ld case. >> >> Thank you all for your help! >&gt...

...gt; > I am not sure what failure you see but our buildbots look mostly green: > http://lab.llvm.org:8011/waterfall > > Please provide more details as it is hard to determine if this is an > LLVM issue or not. > > Thanks, > Johannes > > > On 8/29/20 6:40 PM, Itaru Kitayama via llvm-dev wrote: > > I am seeing in the last couples of days llvm plus other projects builds are > > failing, is this being worked on? > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https...

...nately that would limit you to 4 cores. > > There’s no easy way to use lld with —no-threads with our build system at > the moment unfortunately. > > I also had just been using ld.gold, but will switch now that numactl works > for me. > > On Sat, Mar 28, 2020 at 3:58 PM Itaru Kitayama <itaru.kitayama at gmail.com> > wrote: > >> That is slowing down the build visibly, for the speed I should stick with >> ld at the moment. >> >> >> On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea < >> alexandre.ganea at ubisoft.com> wrote: >&...

...e slow/uses a lot of memory. There are a few > other issues to do with memory usage (do you have less than about a GB of > RAM per CPU? Then you'll probably hit swapping by default & have a bad time > - there are ways around that) > > > On Thu, Jan 2, 2020 at 5:42 PM Itaru Kitayama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> When building LLVM, is it always recommended to do it with the >> latest official release, currently, it is 9.0.1? I ask because when I >> tried >> it with a Debug build, it took an enormous am...

That is slowing down the build visibly, for the speed I should stick with ld at the moment. On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > Would `taskset -c 0-3 ninja check-all -j4` work? > > > > *De :* Itaru Kitayama <itaru.kitayama at gmail.com> > *Envoyé :* March 28, 2020 3:37 PM > *À :* Alex Brachet-Mialot <alexbrachetmialot at gmail.com> > *Cc :* Alexandre Ganea <alexandre.ganea at ubisoft.com>; LLVM Dev < > llvm-dev at lists.llvm.org>; Nemanja Ivanovic <nemanja.i.ibm...

...n 4096 -F -S0 on a 2GB single metadata fs leaves about 400Mb of metadata almost unused. This patch reduces metadata chunk allocations by considering the proper metadata chunk size of 200MB in should_alloc_chunk(), not the default 256MB which is set in __btrfs_alloc_chunk(). Signed-off-by: Itaru Kitayama <kitayama@cl.bb4.ne.jp> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 8c26441..54ab490 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3241,6 +3241,8 @@ static int should_alloc_chunk(struct btrfs_root *root, struct btrfs...

...imiting the number of processes > created (assuming your lld was after that commit) with numactl or taskset. > > In your case though it looked like you were running out of memory. You > could try increasing your swap space? > > Alex > > On Sat, Mar 28, 2020 at 3:15 PM Itaru Kitayama <itaru.kitayama at gmail.com> > wrote: > >> Hi, >> My configuration is below: >> cmake -GNinja -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_THREADS=OFF >> -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_BUILD_TYPE=Release >> -DGCC_INSTALL_PREFIX=/home/usr4/c74014i/opt/gcc-7.5.0/ &gt...

...e an out of tree branch I mean, other than LLVM trunk so I can test how much I can SVE vectorize my code with it? Arm seemed to gave taken down the GitHub branch for sometime. On Wed, Sep 11, 2019 at 20:41 Renato Golin <rengolin at gmail.com> wrote: > On Wed, 11 Sep 2019 at 06:13, Itaru Kitayama via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I'm still seeing the same ie trying to produce SVE instructions but > > resulted in NEONs with Clang as of Sep. 10th. > > http://lists.llvm.org/pipermail/llvm-dev/2019-March/130788.html > > Hi...

...https://github.com/llvm/llvm-project/commit/09158252f777c2e2f06a86b154c44abcbcf9bb74 ? There was a tiny bug in how sched_getaffinity() was used, see: https://reviews.llvm.org/D75153#1942336 De : Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Envoyé : March 28, 2020 12:11 PM À : Itaru Kitayama <itaru.kitayama at gmail.com> Cc : LLVM Dev <llvm-dev at lists.llvm.org>; Alexandre Ganea <alexandre.ganea at ubisoft.com>; Fāng-ruì Sòng <maskray at google.com> Objet : Re: [llvm-dev] LLD issue on a massively parallel build machine I also run into problems with lld on mach...

Hi, I am seeing an LLVM build failure with recent LLD on x86 like: [...] lib/libLLVMCodeGen.a lib/libLLVMBitWriter.a lib/libLLVMScalarOpts.a lib/libLLVMAgg ressiveInstCombine.a lib/libLLVMInstCombine.a lib/libLLVMTransformUtils.a lib/libLLVMDebugInfoDWARF.a lib/lib LLVMMCDisassembler.a lib/libLLVMExecutionEngine.a lib/libLLVMTarget.a lib/libLLVMAnalysis.a lib/libLLVMProfil eData.a

...>> >> There was a tiny bug in how *sched_getaffinity*() was used, see: >> https://reviews.llvm.org/D75153#1942336 >> >> >> >> *De :* Alex Brachet-Mialot <alexbrachetmialot at gmail.com> >> *Envoyé :* March 28, 2020 12:11 PM >> *À :* Itaru Kitayama <itaru.kitayama at gmail.com> >> *Cc :* LLVM Dev <llvm-dev at lists.llvm.org>; Alexandre Ganea < >> alexandre.ganea at ubisoft.com>; Fāng-ruì Sòng <maskray at google.com> >> *Objet :* Re: [llvm-dev] LLD issue on a massively parallel build machine >> &...

Hi, I'm still seeing the same ie trying to produce SVE instructions but resulted in NEONs with Clang as of Sep. 10th. http://lists.llvm.org/pipermail/llvm-dev/2019-March/130788.html -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190910/100290f6/attachment.html>