search for: bigblock

On Jul 29, 2009, at 3:14 PM, Roman Levenstein wrote: > Hi Lang, > > There are at least two projects that were using BigBlock, directly or > indirectly. Hi Roman, We have many plans to rip out linscan and replace it with something that handles large blocks better. That's not the issue :). The problem is that bigblock is unmaintained and bitrotted. Since noone is working on it, it doesn't work, and it...

Hi all, I'd like to kill off the bigblock register allocator. Is anyone still using it? Cheers, Lang.

Hi Lang, There are at least two projects that were using BigBlock, directly or indirectly. One approach is described in the paper "Register Spilling and Live-Range Splitting for SSA-Form Programs" by Matthias Braun and Sebastian Hack. It can be found here: http://pp.info.uni-karlsruhe.de/publication.php?id=braun09cc http://pp.info.uni-karlsruhe.de/up...

Hi Chris, 2009/7/30 Chris Lattner <clattner at apple.com>: > > On Jul 29, 2009, at 3:14 PM, Roman Levenstein wrote: > >> Hi Lang, >> >> There are at least two projects that were using BigBlock, directly or >> indirectly. > > Hi Roman, > > We have many plans to rip out linscan and replace it with something > that handles large blocks better.  That's not the issue :). As far as I know, we have these ambitious plans since a while (just X years), but there is no goo...

...sing only a single register (and the stack, a lot!) for hundreds or thousands of instructions at a time, greatly slowing (+bloating) the code. Luckily, I didn't have the presence of mind to actually try using the local register allocator before I ripped its guts out, turning it into RegAllocBigBlock.cpp that's now in CVS. (Had I done that, I would have been quite happy to find that the local allocator produced much better code, much faster than linearscan.) The good news is the new "BigBlock" allocator turns out to produce even better code than the local allocator when bloc...

...e fairly large functions that are just flat sequences of instructions, anywhere from 100 to 10000+ in size??? It would be nice, if you could send me those test cases (as C or ll files). I could use it then as a basis for a comparision and report about results. > The good news is the new "BigBlock" allocator turns out to > produce even better code than the local allocator when blocks are very > large. We're talking a +10~20% speed boost on average. (If your basic > blocks are small, or there's not much register pressure, you'll > actually get the same code ou...

...39;d be curious to see if your allocator can improve the code enough to justify the extra time spent. > Do you have numbers comparing it to the current version of the LLVM's > linear scan? The win of your allocator over the linear scan should be > even better, I guess. Both local and bigblock are way, way ahead of the linearscan allocator for my application (and I imagine others, such as large unrolled linear algebra kernels, FFTs/codecs etc). On the code I have, performance improves by around 50~100% using the local allocator. Using bigblock gives another 10~20% on top of that, with th...

Hi Roman, > BTW, the research papers that I mentioned are not about improving > register allocation for large blocks (which was the target in the case > of BigBlock). They are about register allocation for general purpose > CFGs. And they report improvements (greatly reduced number of > load/stores for spills) over linear scan. The compilation time is also > comparable with linear scan. So, independent of the BigBlock > discussion they are worse lo...

...thm significantly better over the years. However, we're getting more serious about actually doing something about the core algorithms. > BTW, the research papers that I mentioned are not about improving > register allocation for large blocks (which was the target in the case > of BigBlock). They are about register allocation for general purpose > CFGs. And they report improvements (greatly reduced number of > load/stores for spills) over linear scan. Sure, we won't keep the linscan algorithm. The current LLVM linscan implementation is not linear time in any case, and s...

...think it would be easy to add the LLVM dominator tree once I can compile it (the compilation problem is due to gcc 3.3.3). My next step will be: 1) debug the three benchmarks that are failing: gcc, vpr and vortex 2) add instruction folding Just as an aside, I compared the puzzle solver with the BigBlockAllocator, and the puzzle solver seems to be producing much fewer memory accesses for big basic blocks. For instance, for a basic block with about 8000 instructions, the algorithms produce the following static code: #mem accesses #Moves puzzle 178...

Quoting Bill Wendling <isanbard at gmail.com>: > Hi Nikolaos, > > I have an alpha version of Chow & Hennesey's priority-based graph > coloring algorithm. It's suffering from some bit-rotting -- e.g., > there's some trouble with how it calculates "forbidden" registers. > You're welcome to the code, if you'd like to hack on it. I've been

> > 1. I can see the standard algorithms (bigblock, linearscan -- good > > choice for > > the JIT and for general use as well, and the other algorithms). Is > > it possible > > to pre-allocate registers in your linearscan (or in another > > allocation engine) > > for specific source-level or (better) intermediate...

Hi there i would like to ask a few questions to the developers responsible for the register allocator(s) design in LLVM (Fernando and other people). First of all, congrats on providing more than one option for register allocation. Now to the questions: 1. I can see the standard algorithms (bigblock, linearscan -- good choice for the JIT and for general use as well, and the other algorithms). Is it possible to pre-allocate registers in your linearscan (or in another allocation engine) for specific source-level or (better) intermediate code (bitcode) level variables? Ideally i would to pre-all...

Running the SingleSource tests with llc while debugging my PBQP allocator I noticed that test-suite/SingleSource/UnitTests/Threads/tls.c has some issues with register allocators other than linear scan: Local, simple & bigblock regalloc all cause the following ld assertion failures: bash-3.2$ gcc tls.foo.s -o tls.foo.debug -lm -lpthread /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731 assertion fail ../../bfd/elf64-x86-64.c:2561 /usr/bin/ld: BFD version 2.17.50.0.18-1 20070731 assertion fail ../../bfd/elf64-x86-64.c:...

Hello, On Fri, Nov 14, 2008 at 6:57 PM, H. Johnson <misc at faradayco.com> wrote: > llc -march=x86 tempfileB.bc yields: > llc: for the -march option: : Cannot find option named 'x86'! Run llc -help and see, if any backends were linked in. It will show you list of all backends, which were 'registered' and thus known to llc. -- With best regards, Anton Korobeynikov

llc -march=x86 tempfileB.bc yields: llc: for the -march option: : Cannot find option named 'x86'! Windows build using Visual Studio 2008 Express with CMake. clang and other tools seem to also complain about the format of -march, but other command line arguments seem to be working. Tools, clang llvm-as, opt, etc., "seem" to be working. Incidently, the bytecode file was