search for: joinintervals

I've tried to implement the isMoveInstr method from TargetInstrInfo class, and the register allocator immediately started to crash, in: #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) at ../lib/CodeGen/LiveIntervals.cpp:493 493 assert(r2iA != r2iMap_.end()); The instruction it crashes is: (gdb) p $4.dump() %reg1056 = move %gr7 And gr7 is exactly the register which is looked up with Reg2IntervalMap::iterator r2iA = r2iMap_.find(re...

...happening in this case. > > Also, LiveIntervalAnalysis doesn't do any subregister checks as > far as I can tell. It's certainly not the case that subregister > intervals contain all of the information their supperregister's > interval contains. SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical register with a virtual one the first thing it check is sub-registers. > > > So is this just supposed to be a conservative update for the > purposes of coalescing? > > > In any event, it seems not to be working right if what you > describe is...

...this is a bad > idea. I would much rather have the coallescer be responsible for updating > the code. I would suggest doing this as a first step, it is clearly > goodness :) This is what I was trying to get at, but wasn't entirely clear about. Does the loop nest after the call to joinIntervals in LiveIntervals::runOnMachineFunction do this rewrite? Specifically: // perform a final pass over the instructions and compute spill // weights, coalesce virtual registers and remove identity moves. const LoopInfo &loopInfo = getAnalysis<LoopInfo>(); for (MachineFunction...

...oni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:2769:0 #10 0x0000000001fdcbd5 (anonymous namespace)::RegisterCoalescer::joinVirtRegs(llvm::CoalescerPair&) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:2832:0 #11 0x0000000001fdd174 (anonymous namespace)::RegisterCoalescer::joinIntervals(llvm::CoalescerPair&) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:2892:0 #12 0x0000000001fd5fc3 (anonymous namespace)::RegisterCoalescer::joinCopy(llvm::MachineInstr*, bool&) /d/en/johnsoni-0/gctools/llvm/lib/CodeGen/RegisterCoalescer.cpp:1468:0 #13 0x0000000001fdd4b6 (a...

On Thu, 2004-07-01 at 09:26, Vladimir Prus wrote: > I've tried to implement the isMoveInstr method from TargetInstrInfo class, and > the register allocator immediately started to crash, in: > > #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) > at ../lib/CodeGen/LiveIntervals.cpp:493 > 493 assert(r2iA != r2iMap_.end()); > > The instruction it crashes is: > > (gdb) p $4.dump() > %reg1056 = move %gr7 > > And gr7 is exactly the register which is looked up with > &...

...r crashes. Here's machine code: %reg1030 = - %reg1027, 1 %reg1031 = move %reg1030 %reg1032 = + %reg1031, -2 %reg1033 = move %reg1032 %ar1 = load64 %gr1<def>, %reg1033 and here's assertion: llc: LiveIntervals.cpp:507: void llvm::LiveIntervals::joinIntervals(): Assertion `rcA == rcB && "registers must be of the same class"' failed. (gdb) up 4 ..... (gdb) p *intA $1 = (llvm::LiveInterval &) @0x8064698: {reg = 1030, weight = 0, ........ (gdb) p *intB $2 = (llvm::LiveInterval &) @0x80646b8: {reg = 1031, weight = 0, ..........

...idea. I would much rather have the coallescer be responsible for updating >> the code. I would suggest doing this as a first step, it is clearly >> goodness :) > > This is what I was trying to get at, but wasn't entirely clear about. > Does the loop nest after the call to joinIntervals in > LiveIntervals::runOnMachineFunction do this rewrite? I didn't think anything did, but... > Specifically: > > // perform a final pass over the instructions and compute spill > // weights, coalesce virtual registers and remove identity moves. > const LoopInfo &...

On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > > In other words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? >

On Jul 16, 2007, at 9:12 AM, David Greene wrote: > On Friday 13 July 2007 13:32, David A. Greene wrote: >> On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: >>> Could it be possible for there to be a harness type interface that >>> would allow coalescers that support both modes to be hooked into the >>> pass registration, and those that depend on the

...> > Also, LiveIntervalAnalysis doesn't do any subregister checks as > > far as I can tell. It's certainly not the case that subregister > > intervals contain all of the information their supperregister's > > interval contains. > > SimpleRegisterCoalescing::JoinIntervals(). When coalescing a physical > register with a virtual one the first thing it check is sub-registers. Right. I'm just wondering why LiveIntervalAnalysis doesn't do this as well. It's not a big deal, because I think LiveIntervalAnalysis is ok as-is. Just curious. > > My as...

On Friday 13 July 2007 13:32, David A. Greene wrote: > On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > > Could it be possible for there to be a harness type interface that > > would allow coalescers that support both modes to be hooked into the > > pass registration, and those that depend on the allocator not be > > registered as passes? > > I have a

...code for merging live intervals and remove copy instructions. This code updates a bunch of dataflow information so it's important that other register coalescers can use it. During the course of this work, I noticed something odd. In the current coalescer, we have this sequence: 00298 if (JoinIntervals(DstInt, SrcInt)) { [...] 00322 } else { [...] 00332 } Ok, at this point intervals were joined and in the process, DstInt and SrcInt might have been swapped by LiveInterval::join. 00334 bool Swapped = repSrcReg == DstInt.reg; 00335 if (Swapped) 00336 std::swap(repSrcReg, repDstReg); 00...

...uld much rather have the coallescer be responsible for >> updating >> the code. I would suggest doing this as a first step, it is clearly >> goodness :) > > This is what I was trying to get at, but wasn't entirely clear about. > Does the loop nest after the call to joinIntervals in > LiveIntervals::runOnMachineFunction do this rewrite? Specifically: > > // perform a final pass over the instructions and compute spill > // weights, coalesce virtual registers and remove identity moves. > const LoopInfo &loopInfo = getAnalysis<LoopInfo>(); &...

On Oct 20, 2012, at 1:23 PM, Vincent Lejeune <vljn at ovi.com> wrote: > below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. > The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. >

On Feb 20, 2008, at 12:25 PM, David Greene wrote: > On Wednesday 20 February 2008 14:14, David Greene wrote: > >> I discovered this through an assert I put into some of my own >> code. I want >> to know if that assert is bogus or if there's a bug here. > > A little more information: the assert checks that after coalescing > two nodes, > all subregister

...nymous namespace)::JoinVals::getAssignments (this=0x7fffffffd230) at RegisterCoalescer.cpp:1305 #6  0x00000000010cb459 in (anonymous namespace)::RegisterCoalescer::joinVirtRegs (this=0x21b62b0, CP=...) at RegisterCoalescer.cpp:1861 #7  0x00000000010cb646 in (anonymous namespace)::RegisterCoalescer::joinIntervals (this=0x21b62b0, CP=...) at RegisterCoalescer.cpp:1883 #8  0x00000000010c84b4 in (anonymous namespace)::RegisterCoalescer::joinCopy (this=0x21b62b0, CopyMI=0x21e8cf8, Again=@0x7fffffffd7a2: false) at RegisterCoalescer.cpp:1002 #9  0x00000000010cb830 in (anonymous namespace)::RegisterCoalescer::copy...

On Thu, 12 Apr 2007, David Greene wrote: > As I work toward improving LLVM register allocation, I've > come across the need to do some refactoring. cool. :) One request: Evan is currently out on vacation until Monday. This is an area that he is very interested in and will want to chime in on. Please don't start anything drastic until he gets back :). > Specifically, I would

Hi all, As I work toward improving LLVM register allocation, I've come across the need to do some refactoring. Specifically, I would like to separate register coalescing from live interval analysis. Right now LiveIntervals handles both. The reason I want to separate them is that other types of register allocators might like to do coalescing differently (e.g. graph coloring does it by

...igned int, bool)+0x8cb)[0x863ede9] llc(llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*, std::vector<llvm::SimpleRegisterCoalescing::CopyRec, std::allocator<llvm::SimpleRegisterCoalescing::CopyRec> >*, bool)+0x132)[0x863f24c] llc(llvm::SimpleRegisterCoalescing::joinIntervals()+0x3de)[0x863f69c] llc(llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)+0x239)[0x863fc65] llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x28)[0x83c9540] llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x13a)[0x8764e7c] llc(llvm::Funct...

Hi, below is an output of "llc -march=r600 -mcpu=cayman -print-before-all -debug-only=regalloc file.shader" command from llvm3.2svn. The register coalescing pass crashes when joining vreg12:sel_z with vreg13 registers, because it tries to access the interval liveness of vreg13... which is undefined. I don't know if it's a bug of the pass, or if my backend should do something