similar to: [LLVMdev] VirtRegMap GLIBCXX assert

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

On May 27, 2008, at 5:36 PM, David Greene wrote: > 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

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)

I am trying to compile an application on a CentOS 5.0 64-bit machine that gives me the error: /usr/local/bin/myprog: /usr/lib64/libstdc++: version `GLIBXX.3.4.9' not found (required by /usr/local/bin/myprog) I have gcc 4.2.3. I've performed a yum install compat-* and glibc* What am I missing? Thanks. Scott

I'm trying to piece together a few assignments for a graduate-level compilers class using LLVM; among these is a register allocator. I'd like to provide a register allocator that, given a partially-allocated VirtRegMap, will perform trivial register allocation (as in RegAllocSimple) on the remaining, unmapped virtual registers. To make a long story short, I want to map a single

On Sep 19, 2008, at 2:41 AM, Matt Elder wrote: > I'm trying to piece together a few assignments for a graduate-level > compilers class using LLVM; among these is a register allocator. I'd > like to provide a register allocator that, given a partially-allocated > VirtRegMap, will perform trivial register allocation (as in > RegAllocSimple) on the remaining, unmapped virtual

Hi Evan, > Ok. Everyone has different idea about "easy". :-) I second your opinion that it is not very easy to use and it is very tightly coupled with the current linear scan register allocator implementation. > But VirtRegMap is going to be remove one of these days. When are you going to do that? Are you going to remove it from the source tree? Will it be replaced with

On Friday 19 September 2008 11:37, Evan Cheng wrote: > Please avoid using VirtRegMap. It's very tied to the current register > allocation pieces and not easily reusable. One of my mission in life > is to kill it. Im surprised to see this. I found it rather easy to re-use for custom register allocators. -Dave

I just updated from upstream llvm as of about last Thursday and I'm getting a segfault in VirtRegMap::RemoveMachineInstrFromMaps. It seems that the particular instruction being removed happens to reference an object at stack slot 4. The first spilled register is assigned stack slot 6 so LowSpillSlot == 6. Then, when we try to erase from SpillSlotToUsesMap, we index with a negative number.

On May 8, 2008, at 11:36 AM, David Greene wrote: > I just updated from upstream llvm as of about last Thursday and I'm > getting a segfault in VirtRegMap::RemoveMachineInstrFromMaps. > It seems that the particular instruction being removed happens > to reference an object at stack slot 4. The first spilled register is > assigned stack slot 6 so LowSpillSlot == 6. Then, when

On Thursday 08 May 2008 16:25, Evan Cheng wrote: > > Since we're hooking up llvm to custom code, I want to check > > assumptions. > > Is there anything in llvm-gcc or the other llvm tools that could > > generate a > > stack slot reference like this before register allocation? > > Basically, I'm > > Codegen can definitely create stack slots during

Yeah, I think so. It should be pretty simple to fix though. Can you provide a patch? Or please fix a bug. Evan On May 8, 2008, at 2:32 PM, David Greene wrote: > On Thursday 08 May 2008 16:25, Evan Cheng wrote: > >>> Since we're hooking up llvm to custom code, I want to check >>> assumptions. >>> Is there anything in llvm-gcc or the other llvm tools that

On Friday 09 May 2008 14:41, Evan Cheng wrote: > Yeah, I think so. It should be pretty simple to fix though. Can you > provide a patch? Or please fix a bug. Yep, I can provide a patch. -Dave

Ping. Have you had a chance to address this bug? Thanks, Evan On May 9, 2008, at 1:17 PM, David Greene wrote: > On Friday 09 May 2008 14:41, Evan Cheng wrote: >> Yeah, I think so. It should be pretty simple to fix though. Can you >> provide a patch? Or please fix a bug. > > Yep, I can provide a patch. > > -Dave >

On Wednesday 21 May 2008 13:18, Evan Cheng wrote: > Ping. Have you had a chance to address this bug? Thanks for the reminder. I just checked it in. -Dave

On Friday 30 May 2008 15:13, Evan Cheng wrote: > No, every vr is assigned a physical register. It needs to know how > what physical register to reload it, for example. Looks like > SimpleSpiller has bit-rotted. There really isn't a good reason to fix > it. Unless you want to use it, I'll just remove it. No, don't remove it! It's a valuable debugging tool. I've

Hi Susan, With your bitcode file I am now able to reproduce the issue you're seeing. It looks like this is a problem with the naive rewriting from virtregs to physregs. It appears that the subreg field of physreg operands is ignored post-register allocation. In your testcase %vreg11:sub32 is being rewritten to RBX:sub32, but the :sub32 part is being quietly dropped when the assembly is

Hi Susan, Sorry for the delayed response. Thanks for the test cases - I'm looking in to this now. - Lang. On Mon, Nov 5, 2012 at 2:58 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote: > Hi Lang, > > I looked more into one of the problems I'm now having, and I've attached 3 > files: > > Gcra.cpp is like your version except that for two specific vregs it uses

I am hitting this assert in LLVM 2.5: /// spillPhysRegAroundRegDefsUses - Spill the specified physical register /// around all defs and uses of the specified interval. void LiveIntervals::spillPhysRegAroundRegDefsUses(const LiveInterval &li, unsigned PhysReg, VirtRegMap &vrm) { unsigned SpillReg = getRepresentativeReg(PhysReg); for (const

Hi Lang, I looked more into one of the problems I'm now having, and I've attached 3 files: Gcra.cpp is like your version except that for two specific vregs it uses hard-coded pregs instead of the first in the corresponding class. bug1.c is an input that causes the failed assertion for me. If I use the non-debug version of LLVM-3.1 I instead get assembler errors like this: Error: