similar to: GlobalISel BoF follow-up

Hi again, On 1 April 2017 at 15:09, Diana Picus <diana.picus at linaro.org> wrote: > If people feel it would be useful, we could also try to send a > weekly-ish email listing the pending reviews and any points that need > coordination. We're open to any suggestions on how we can communicate > better. Nobody said anything about this, but with people coming back from spring

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

Hi Kristof, > On Apr 27, 2017, at 9:47 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Quentin, > >> On 27 Apr 2017, at 00:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >>> On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com

Hi Kristof, > On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > I've been digging a little bit deeper into the biggest performance regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving floating point values through general purpose registers. I've

Great Quentin :). I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2" on r302453, on AArch64 Cortex-A57. I indeed see almost no moves between GPR and FPR registers anymore (see details below for where I still see some). On geomean, I see 13% slow down (down from 17% on my previous run). On geomean, code size increase

Hi Quentin, On Tue, May 9, 2017 at 11:47 AM Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kristof, > > On May 9, 2017, at 3:41 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Great Quentin :). > > I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm > -global-isel -mllvm

I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2". I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are. This was running on Cortex-A57 AArch64 Linux. I saw one assertion

On 18 May 2017 at 19:09, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > >> On May 18, 2017, at 1:15 AM, Diana Picus <diana.picus at linaro.org> wrote: >> >> 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

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?

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

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

Hi Quentin, I actually did a run with -mllvm -optimize-regalloc -mllvm -regalloc=greedy over the weekend and the test does pass with that. Haven't measured the compile time though. Cheers, Diana On 19 May 2017 at 19:06, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Diana, > > On May 19, 2017, at 1:33 AM, Diana Picus <diana.picus at linaro.org> wrote: > >

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

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

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 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

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

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

Great, good to know it's not just a problem with our bot. Thanks! On 28 August 2017 at 16:24, Chris Matthews <cmatthews5 at apple.com> wrote: > Hi Diana, > > I have seen that issue on some other bots too. I will fix it this week. It is something about how MySQL treats character encodings differently than Postgres. We are checking for the value in the table beforehand, and this

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