similar to: AArch64 buildbots and PR33972

I'd like to mention that test does not allocate 30TB, it allocates 1TB, the rest, ~20TB, is reserved (but not actually used) for ASan shadow memory, it should not be a problem by itself. The test on your bot failed because it tried to reserve 27TB of memory, which is more than set by ulimit earlier in this test. I do not immediately see why it wants to reserve that much shadow for AArch64

Hello, Some of our AArch64 bots have started timing out while compiling SingleSource/UnitTests/Vector/AArch64/aarch64_neon_intrinsics. On clang-cmake-aarch64-quick the failure first appears between r275337 and r275351, and on clang-cmake-aarch64-full it appears after r275352, so there's isn't a clear culprit for this. I suspect we have been slowly approaching that threshold for a while.

Hi, I've seen this issue pop up on the mailing list a couple of times before with no resolution [1][2][3]. It has been getting really bad for our AArch64 buildbots lately. You can see a few examples at the end of my email [4], but we have the same failures on a couple of other bots as well. Does anyone have any idea how to reproduce / investigate these issues? If not, is it reasonable to

Hi all, We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it. *** Why Is That? *** We don’t want to send the wrong message that GlobalISel’s design is set in stone and ready for broader adoption. In particular, 1. The APIs are still evolving and can still possibly change significantly 2. The TableGen backend to reuse the existing SD

On 12 June 2017 at 18:54, Diana Picus <diana.picus at linaro.org> wrote: > Hi all, > > I added a buildbot [1] running the test-suite with -O0 -global-isel. It > runs into the same 2 timeouts that I reported previously on this thread > (paq8p and scimark2). It would be nice to make it green before flipping the > switch. > > I did some more investigations on a machine

> On Jun 16, 2017, at 4:58 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Fri, Jun 16, 2017 at 4:43 PM Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > Hi all, > > We had some internal discussions about flipping the default for O0 and we concluded that we wanted to postpone it. > > > *** Why

> On 19 May 2017, at 14:54, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > r303259 will have increased compile-time since it tripled the number of importable > SelectionDAG rules but a quick measurement building the affected file: > ninja lib/Target/<Target>/CMakeFiles/LLVM<Target>CodeGen.dir/<Target>InstructionSelector.cpp.o > for

Hi Daniel, I did your experiment on a TK1 machine (same as the bots) and for r303258 I get: real 18m28.882s user 35m37.091s sys 0m44.726s and for r303259: real 50m52.048s user 88m25.473s sys 0m46.548s If I can help investigate, please let me know, otherwise we can just try your fixes and see how they affect compilation time. Thanks, Diana On 22 May 2017 at 10:49, Daniel

Nope, no sanitizers. On 22 May 2017 at 11:38, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > Is that with -fsanitize=memory too? > > I'm currently building ToT with r303258 reverted. Once that's done I'll commit the revert and start investigating fixes. > >> On 22 May 2017, at 10:22, Diana Picus <diana.picus at linaro.org> wrote: >>

Thanks for trying that patch. I agree that 34 mins still isn't good enough but we're heading in the right direction. Changing the partitioning predicate to the instruction opcode rather than the number of operands in the top-level instruction will hopefully cut it down further. I also have a patch that shaves a small amount off of the compile-time by replacing the various

Hi Diana and Vitaly, Could you give https://reviews.llvm.org/differential/diff/100829/ <https://reviews.llvm.org/differential/diff/100829/> a try? When measuring the compile of AArch64InstructionSelector.cpp.o with asan enabled and running under instruments's Allocation profiler, my machine reports that the cumulative memory allocations is down to ~3.5GB (was ~10GB), the number of

It must be r303341, I commented on corresponding llvm-commits thread. On Fri, May 19, 2017 at 7:34 AM, Diana Picus via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Ok, thanks. I'll try to do a bisect next week to see if I can find it. > > Cheers, > Diana > > On 19 May 2017 at 16:29, Daniel Sanders <daniel_l_sanders at apple.com> > wrote: > > >

Is https://reviews.llvm.org/differential/diff/100829/ replacement for r303341? If so LGTM. r303542 msan AArch64InstructionSelector.cpp: 1m17.209s r303542+diff/100829/ <https://reviews.llvm.org/differential/diff/100829/> msan AArch64InstructionSelector.cpp: 1m24.724s On Wed, May 31, 2017 at 6:13 AM, Daniel Sanders <daniel_l_sanders at apple.com> wrote: > Great! I expect

Hi, We've noticed that recently some of our bots (mostly clang-cmake-armv7-a15 and clang-cmake-thumbv7-a15) started timing out whenever someone commits a change to TableGen: r303418: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7268 r303346: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7242 r303341:

Hi Quentin, My only remaining concern is around ABI compatibility. The following commit seems to indicate that in the previous round of evaluation, we didn’t find an existing ABI compatibility issue: http://llvm.org/viewvc/llvm-project?view=revision&revision=311388. I haven’t looked into the details of this issue - so maybe I’m worried over nothing? I’m wondering if since then on your side

On Tue, May 23, 2017 at 10:51 AM Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Could you give https://reviews.llvm.org/differential/diff/99949/ a try? > It brings back the reverted commit and fixes two significant compile-time > issues. Assuming it works for you too, I'll finish off the patches and post > them individually. > > The first one

Great! I expect I'll be able to cut it down further once I start fusing these smaller state-machines together. Before that, I'll re-order the patches that went into that diff so that I don't have to re-commit the regression before fixing it. > On 31 May 2017, at 13:48, Diana Picus <diana.picus at linaro.org> wrote: > > Hi, > > This runs in: > real

Turns out it really is a GlobalISel issue - we eat up too much stack space because all the constants used in the switches are stored on the stack. We need to fix this somehow before changing the default. I'll try to give it a run with Quentin's r299283 on top to see if it helps. Cheers, Diana On 15 May 2017 at 09:38, Diana Picus <diana.picus at linaro.org> wrote: > Got another

Agreed. That was probably just luck before :) -eric On Fri, May 12, 2017 at 5:22 AM Diana Picus via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It turns out that can be fixed by adding -lm to the link line, so I > will probably convert it into a test-suite bug. > > I don't suppose it's crucial to handle the fabs intrinsic nicely at -O0. > > On 12 May 2017 at

On 18 May 2017 at 09:06, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > I think Diana found that when enabling r299283, the bootstrap failed with > llvm-tblgen segfaulting. > So there clearly is some work required there. Indeed. @Quentin, what is the status of that patch? Have you been working on it since then? Should I investigate the segfault more and send you a reproducer?