search for: pr32550

...trying to keep the scratchpad document here [1] up to date, but I'll try to summarize things on the mailing list as well: We still have a few bugs open that we should fix or at least discuss before turning GlobalISel on by default at O0 for AArch64: * PR32560 - A crash in regbank select [2] * PR32550 - Floating point values moving a lot through GPRs [3] * PR32561 - Improve placement of constants [4] * Optional - improve handling of switch statements (I think we don't even have a bug open for this, but it has been brought up) Unrelated to O0, here are some pending patches (at least that I...

Hi all, At the EuroLLVM BoF people asked where the design discussions around GlobalISel take place. Naturally, a lot of them take place at Apple, since they have the highest density of co-located GlobalISel devs, but we also have some in Phab. For those of you that are interested, please have a look at the following topics - discussions are progressing rather slowly and we definitely

...l path :). > I think that no matter whether we decide to switch the default before or after fixing this issue, this is one of the most urgent issues to fix as far as I can see. Agree. This is one of the top items of my todo list. > > If there is some way I can help contribute to fixing PR32550, I would like to help; but with the dependency on tablegen generation, I'm not sure what the best way is to help make that PR get fixed faster? Thanks for offering to help. I agree that with the dependency on the tabelgen generation in the way, this is probably not a good use of your time. Dep...

...tants, 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) On 8 May 2017, at 20:38, Quentin Colombet <qcolombet at apple.com<mailto:qcolombet at apple.com>> wrote: Hi Kristof, I made a fix for PR32550, that is much less involved in r302453. In particular, it does not rely on the greedy mode of the regbankselect pass, thus there is no compile time implication. Could you try it and check where we stand? Thanks, -Quentin On Apr 27, 2017, at 10:40 AM, Quentin Colombet via llvm-dev <llvm-dev at...

...localizes (as in basic block local) the definition of the constants to > workaround the limitations of O0 regalloc. > > Cheers, > -Quentin > > > > On 8 May 2017, at 20:38, Quentin Colombet <qcolombet at apple.com> wrote: > > Hi Kristof, > > I made a fix for PR32550, that is much less involved in r302453. > > In particular, it does not rely on the greedy mode of the regbankselect > pass, thus there is no compile time implication. > > Could you try it and check where we stand? > > Thanks, > -Quentin > > On Apr 27, 2017, at 10:40 AM...

...the limitations of O0 regalloc. > > Cheers, > -Quentin >> >> >>> On 8 May 2017, at 20:38, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >>> >>> Hi Kristof, >>> >>> I made a fix for PR32550, that is much less involved in r302453. >>> >>> In particular, it does not rely on the greedy mode of the regbankselect pass, thus there is no compile time implication. >>> >>> Could you try it and check where we stand? >>> >>> Thanks, >&g...

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