similar to: [LLVMdev] Register allocation problems with TLS unit test.

Hi everyone, This is a quick status update regarding the PBQP (Partitioned Boolean Quadratic Programming) register allocator. A quick overview of the project: PBQP is a heavyweight allocation technique intended for native code compilation, and compilation of performance critical sections. It works by modeling register allocation problems as PBQP problems, solving these using a generic solver, and

Hello! I have encountered a problem when building shared klibc with recent binutils versions - apparently the breakage happened since binutils 2.17.50.0.2 due to the following change: http://sources.redhat.com/ml/binutils/2006-05/msg00279.html http://sourceware.org/ml/binutils/2006-05/msg00466.html --- a/binutils/bfd/elf64-x86-64.c +++ b/binutils/bfd/elf64-x86-64.c @@ -3630,7 +3630,8 @@ static

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.

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/uploads/publikationen/braun09cc.pdf

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

Hi Roman, > True. I'm working on the version of the linear scan based on Wimmer's > thesis. It supports live range splitting. I'd like to compare it with > yours. Do you have any good examples of those fairly large functions > that are just flat sequences of instructions, anywhere from 100 to > 10000+ in size??? You can find a couple attached to bug #1512, but I'm

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

Hi Duraid, > Hi everyone, > > Quick summary: > > LLVM now has a new register allocator particularly suitable for > compiling (very) large, machine-generated functions. Congrats! Very good job! > Longer story: > > I've recently been using LLVM in an application that involves JITing > > fairly large functions that have no control flow - they're

Hi everyone, Quick summary: LLVM now has a new register allocator particularly suitable for compiling (very) large, machine-generated functions. Longer story: I've recently been using LLVM in an application that involves JITing fairly large functions that have no control flow - they're just flat sequences of instructions, anywhere from 100 to 10000+ in size. (The control flow is

On Fri, Jun 2, 2017 at 2:34 PM, Ed Maste via llvm-dev < llvm-dev at lists.llvm.org> wrote: > One additional use case for you: converting from a binary to an ELF object > file > ``` > objcopy -I binary -O elf64-x86-64 foo.bin foo.o > ``` > This is sometimes used for embedding binary files for use by drivers and > such. > Yea, unfortunately the command-line you

Hi Duncan, >> New PBQP solver. > > nice! Any chance of a quick summary of the state of the pbqp allocator and > who might want to use it? Sure. Here's an update, broken into three handy sections: Summary for LLVM users: --- PBQP is a heavyweight register allocator. A quick, not-at-all scientific look at SPEC2006 shows that compiling with -regalloc=pbqp increased runtime

- Re-sending to include llvm-dev. HI Jonas, This is great - thank you very much for your analysis! You're spot on about Bug 1 - the row/column checks are transposed there. I have fixed this in r227628. Regarding Bug 2, as discussed on the other thread I'm going to teach the register allocator to prune single-option vregs so that they never make it into the graph. I haven't had a

On Mar 17, 2011, at 8:44 AM, Renato Golin wrote: >> dwarfdump --verify will do this. > > Is this being used in LLVM tests? This is an idea. It is not used in llvm/test tests. > I had a look at your debug tests in clang and they're similar to what I do here. > > The problem with debug tests is that it doesn't depend only on the > compiler, but on the debugger

Hi All, I've just committed some changes to the PBQP allocator which are designed to make it easier to implement custom register allocation constraints. This is a quick summary of those changes, and of the status of the PBQP allocator in general. First a quick bit of background: The PBQP allocator is based on ideas described in [1]. I implemented this algorithm (with the improved heuristic

Hi, Sorry for the delay, it has taken some extra time as more than one bug showed up ☺ I continued to look into this with your viewpoint that a node that is conservatively allocatable should never be spilled. The first thing I did was therefore to add some extra code with an assert for this. I believe I then found three bugs and fixed the two: Bug 1: Incorrect transpositions in handleAddEdge()

Hi Arnaud, Thanks for attaching those files. I'll take a look at them. Commit r153483 adds an option to the PBQP allocator, "-pbqp-dump-graphs", to dump the PBQP graph for each round of each function in a compilation unit. The generated files are named "<module id>.<function>.<round>.pbqpgraph", and contain a simple text representation of the PBQP graph.

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

On 17 March 2011 18:45, Devang Patel <dpatel at apple.com> wrote: > Yes, It'd be good to have a setup to build SingleSource and MultiSource tests with debug info and run dwarfdump --verify on them. I tried some dwarfdump on a few examples I had and the comparison with codesourcery's gcc is impossible, the resulting Dwarf is very different. For instance, GCC declares the types at

Hi Arnaud, LiveInterval::markNotSpillable() sets the live interval's spill weight to infinity. For well-formed PBQP graphs (i.e. ones that have some finite-cost solution), PBQP should never chose to spill such an interval. The two possibilities for this crash are that the input graph has no finite-cost solution, or that you've exposed a bug in the PBQP solver. >From memory your target

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of