similar to: [LLVMdev] "Ran out of registers during register allocation" bug affecting ffmpeg

On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote: > See http://llvm.org/bugs/show_bug.cgi?id=4668 and > http://llvm.org/bugs/show_bug.cgi?id=5010. The basic description of > the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The > fundamental problem is we can't spill a register once it's fixed to a > physical register." > >> From discussion

On Mon, Aug 30, 2010 at 5:52 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Aug 21, 2010, at 5:27 PM, Eli Friedman wrote: > >> See http://llvm.org/bugs/show_bug.cgi?id=4668 and >> http://llvm.org/bugs/show_bug.cgi?id=5010.  The basic description of >> the issue (from http://llvm.org/bugs/show_bug.cgi?id=4668#c5): "The >> fundamental problem

--- Chris Lattner <sabre at nondot.org> wrote: > On Thu, 21 Dec 2006, Roman Levenstein wrote: > > following: > > 1) some of the fixed registers intervals are merged with some > virtual > > registers intervals > > 2) later there is a need to spill one of the allocated registers, > but > > since all joined intervals are FIXED intervals now due to (1),

Hello Jakob, > Those are some severe constraints on register allocation, but it ought to > be possible anyway. > Indeed, these constraints aren't playing very well with the register allocator :\ > > You may wan't to investigate how RAGreedy::canEvictInterference() is > behaving. > Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

Hi! I'm developing a register allocator that works iteratively. It spills some virtual registers on each iteration until all the rest have physical ones assigned. How can I spill some live intervals at the end of each iteration with new live intervals having correct weights? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm having no luck getting my register allocator to work. I'm trying to do it using the "indirect" approach; i.e., using a VirtRegMap, with calls to assignVirt2Phys, assignVirt2StackSlot, etc. and a call to a "spiller" at the end. As a warm-up exercise (before implementing register allocation via graph coloring) I'm trying to implement a very simple scheme in

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No

On Sun, 6 Aug 2006, Anton Vayvod wrote: > I'm developing a register allocator that works iteratively. It spills some > virtual registers on each iteration until all the rest have physical ones > assigned. Take a look at the linear scan allocator. It is also iterative: it uses the spiller interface to insert spill code, which creates (unspillable) intervals for the spill code it

Hi Jakob, I've got a good test case that I'm working on at the moment. I noticed something odd though: Is '0' a valid register unit? I'm seeing a LiveInterval with li->reg == 0 show up, which previously wasn't valid. We have a few checks around the place to disregard the '0' physreg - could these trigger on interaction with a '0' interval? That could

Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. As a workaround, instead of marking them as not spillable, I've marked them with a very high spill cost and the regalloc is able to compile the function with good code

On Jan 9, 2013, at 10:46 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Ok, I've found that marking tiny live intervals as not spillable inside VirtRegAuxInfo::CalculateWeightAndHint is not playing nicely with very constrained regclasses, in my case a regclass composed of only one register. > As a workaround, instead of marking them as not spillable, I've marked them

Hi GCC and LLVM developers, I am learning Register Allocation algorithms and I am clear that: * Unlimited VirtReg (pseudo) -> limited or fixed or alias[1] PhysReg (hard) * Memory (20 - 100 cycles) is expensive than Register (1 cycle), but it has to spill code when PhysReg is unavailable * Folding spill code into instructions, handling register coallescing, splitting live ranges, doing

OK, details: I run RH8 (gcc 3.2.something), RH9 (gcc 3.2.2-5) and Fedora. Problems are the same across all setups. Hardware is Athlon 1600+ and half a giga RAM. Runs fail with an assertion when the linear scan allocator is enabled, but runs without problems otherwise. On RH9 (the system I have access to while generating this email) I have the following details: > 1) The LLVM assembly

Hello Jakob, I think I've found something interesting that may help you get a better idea of what's going on. While looking at the debug info I noticed that the coalescer was removing lots of copies that could help the allocator make more cross class copies. As a test, I disabled the join-liveintervals option in the coalescer which gave me the surprise of making the regalloc succeed. To

Hello Matthias, On 28 July 2017 at 04:13, Matthias Braun <mbraun at apple.com> wrote: > It's not that hard in principle: > - A register class is a set of registers. > - Virtual Registers have a register class assigned. > - If you have register constraints (like x86 8bit operations only work on > al,ah,etc.) then you have to create a new register class to express that.

Thanks Jakob. I should have mentioned that earlier. :) When you see mismatched sizes on operands it's a fair bet that the subreg rewriting has gone wrong. I should have pulled that entirely out of the preg search loop in the previous example. Fixed version attached. - Lang. -------------- next part -------------- An HTML attachment was scrubbed... URL: