search for: r299283

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 one: https://bugs.llvm.org/show_bug.cgi?id=33036 > > I'm still investigating whether this is an actual GlobalISel issue or > something else (I'l...

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? Is this patch the way forward,...

...t <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 segfaulting. >>> So there clearly is some work required there. >> >> Indeed. >> >> @Quentin, what is the status of that patch? > > Initially it was meant as a prototype to investigate how we could address tho...

...in 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 segfaulting. > So there clearly is some work required there. > > > Indeed. > > @Quentin, what is the status of that patch? > > > Initially it was meant as a prototype to investigate how we could address > those issues at O0....

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

...y due to creating constants always in the > entry BB of the function. For functions with many constants, this leads to > lots and lots of constant creation and then immediately spilling it to the > stack. (https://bugs.llvm.org//show_bug.cgi?id=32561) > > > About a month (r299283), I mistakenly committed a prototype I was working > on to solve this kind of issue. I reverted it in r299287, but you can > give it a try. > > Basically, that’s an additional generic pass that runs only at O0. It > localizes (as in basic block local) the definition of the constants...

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

...ts always in the entry BB of the function. For functions with many constants, this leads to lots and lots of constant creation and then immediately spilling it to the stack. (https://bugs.llvm.org//show_bug.cgi?id=32561 <https://bugs.llvm.org//show_bug.cgi?id=32561>) > > About a month (r299283), I mistakenly committed a prototype I was working on to solve this kind of issue. I reverted it in r299287, but you can give it a try. > > Basically, that’s an additional generic pass that runs only at O0. It localizes (as in basic block local) the definition of the constants to workaround...