similar to: [LLVMdev] Register Allocation, Spill Weight calculation

Hi, While investigating a performance issue with an internal codebase I came across what looks to be poor register allocation. I have constructed a small(ish) reproducible which demonstrates the issue (see test.ll attached). I have spent some time going through the register allocator to understand what is happening. I have also experimented with some small changes to try and improve the

I have encountered a rather odd situation with Greedy where it will end up spilling a register that was populated with a zero (with a trivially rematerializable load-immediate instruction). In fact, it spills 3 such values (LICM moves stuff out of a loop, register coalescer replaces copies with load-immediates and then Greedy spills them). I personally can't think of a situation where a spill

I do have a reproducer, but it's not for the faint of heart :) This is from a large and messy C file (Perlbench's regexec.c), reduced by bugpoint down to 1050 lines of IR. Perhaps I can paste it on pastebin. Just for fun, I added some debug dumps for machine instructions that spill registers (i.e. return non-zero from MachineInstr::getFoldedSpillSize()) that are fed by load-immediates and

Hello, For the following test case, reg.c #include <stdio.h> int getinput() { static int u=10; return u++; } int main() { int a,b,c,d,e,f,g; a=getinput(); b=getinput(); c=getinput(); d=getinput(); e=getinput(); f=getinput(); g=getinput(); printf("%d %d %d %d %d %d %d\n",a,b,c,d,e,f,g); a=b=c=d=e=f=g=0; return 0; } *1.

Thanks for the reduced test case, I’ll try to take a look by the end of the week. > On Feb 20, 2019, at 6:53 PM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Finally managed to reduce this to something manageable: https://godbolt.org/z/Hw529k <https://godbolt.org/z/Hw529k> > > On line 40 of the output, we have a load-immediate to put zero into R3. Then we

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.

Hi Jakob, Jonas et al, Jakob wrote: [...] > Jonas wrote: > [...] > > What's more, setting the GPR_CR class to 'not-spillable' would probably do the trick here as we > > basically do not want to do this, and I would not have to pre-allocate. But there is probably a > > better way, or? > > I am sorry, I simply don't understand what you are asking

On Sep 26, 2011, at 2:41 AM, 陳韋任 wrote: >> The greedy allocator is global, but so was the old linear scan allocator. > > In http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html > , it says "The algorithm is local, and it cannot clean up messes that > extend beyond a single basic block". Does it mean the rewriter algorithm > not the linear scan?

On 9/26/2017 6:47 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org >> <mailto:gberry at codeaurora.org>> wrote: >> >> >> >> On 9/26/2017 6:11 PM, Matthias Braun wrote: >>>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev >>>> <llvm-dev at lists.llvm.org

On 9/26/2017 6:11 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is:

> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org> wrote: > > > > On 9/26/2017 6:11 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi all, >>> >>> Mikael reported a machine verification failure in his out-of-tree target

> On Sep 26, 2017, at 8:24 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9/26/2017 6:47 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org <mailto:gberry at codeaurora.org> <mailto:gberry at codeaurora.org <mailto:gberry at codeaurora.org>>> wrote: >>> >>>

The greedy allocator is global, but so was the old linear scan allocator. Cameron On Sep 26, 2011, at 2:12 AM, Carlo Alberto Ferraris <cafxx at strayorange.com> wrote: > Just a quick question: is greedy still a local allocator (i.e. only takes into consideration the current bb) or a global one (takes into consideration the whole function)? > <cafxx.vcf> >

Hi all, Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is: *** Bad machine code: Multiple connected components in live interval *** - function: utils_la_suite_matmul_ref - interval: %vreg77

> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is: > > *** Bad machine code: Multiple connected components in live

Il 26/09/2011 16:49, Jakob Stoklund Olesen ha scritto: > On Sep 26, 2011, at 2:41 AM, 陳韋任 wrote: > >>> The greedy allocator is global, but so was the old linear scan allocator. >> In http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html >> , it says "The algorithm is local, and it cannot clean up messes that >> extend beyond a single basic

On Sep 28, 2011, at 3:08 PM, Chris Lattner wrote: > > On Sep 27, 2011, at 12:11 AM, Leo Romanoff wrote: > >> >> >> It is true that names are not always reflecting the essense. But on the other hand, there is a lot of ongoing research on register allocation (and compilers in general) and it looks like more and more such efforts choose LLVM as a platform for

> The greedy allocator is global, but so was the old linear scan allocator. In http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html , it says "The algorithm is local, and it cannot clean up messes that extend beyond a single basic block". Does it mean the rewriter algorithm not the linear scan? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab,

Just a quick question: is greedy still a local allocator (i.e. only takes into consideration the current bb) or a global one (takes into consideration the whole function)? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110926/d87aa2bd/attachment.html> -------------- next part -------------- A non-text

On Sep 27, 2011, at 12:11 AM, Leo Romanoff wrote: > > > It is true that names are not always reflecting the essense. But on the other hand, there is a lot of ongoing research on register allocation (and compilers in general) and it looks like more and more such efforts choose LLVM as a platform for experimentation. Quite some results and comparisons are published. So, it would be nice