search for: li_

...at the end of the RALinScan::linearScan() function??? E.g. like this: // Add live-ins to every BB except for entry. Also perform trivial coalescing. MachineFunction::iterator EntryMBB = mf_->begin(); SmallVector<MachineBasicBlock*, 8> LiveInMBBs; for (LiveIntervals::iterator i = li_->begin(), e = li_->end(); i != e; ++i) { LiveInterval &cur = *i->second; unsigned Reg = 0; bool isPhys = TargetRegisterInfo::isPhysicalRegister(cur.reg); if (isPhys) Reg = cur.reg; else if (vrm_->isAssignedReg(cur.reg)) Reg = attemptTrivialCoalescing(...

...:1 [0]) > > My assumption was that after MergeInClobberRanges that %reg15 > would contain [458,5168:0 [0]). But it doesn't. So this is the call site? // Update the liveintervals of sub-registers. for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++AS) li_->getOrCreateInterval(*AS).MergeInClobberRanges(*ResSrcInt, li_- >getVNInfoAllocator()); Can you take a look at MergeInClobberRanges() to see what is going on? Otherwise, please file a bug with a test case. Evan > > >...

...rfere. (One caution: LiveInterval::overlaps currently triggers an assertion if the interval passed as a parameter is empty. You'll want to explicitly skip testing of empty intervals. They can just be treated as non-interfering.) To sum up, you probably want something like this: LiveIntervals *li_ = &getAnalysis<LiveIntervals>(); for (LiveIntervals::iterator liItr = li_->begin(), liEnd = li_->end(); liItr != liEnd; ++liItr) { LiveInterval *li = liItr->second; if (li->empty()) continue; for (LiveIntervals::iterator li2Itr = llvm::next(liItr); li2Itr != liEnd; +...

...epDstReg. [...] 00369 // If the intervals were swapped by Join, swap them back so that the register 00370 // mapping (in the r2i map) is correct. 00371 if (Swapped) SrcInt.swap(DstInt); Whoops! At this point repSrcReg is not consistent with SrcInt and the same goes for repDstReg! 00372 li_->removeInterval(repSrcReg); 00373 r2rMap_[repSrcReg] = repDstReg; Does this code get us into trouble due to the inconsistency created above? Is this a bug? There's a lot of indirection going on here and it's hard to keep track of it....

On Jan 13, 2009, at 12:27 AM, Roman Levenstein <romix.llvm at googlemail.com > wrote: > 2009/1/13 Evan Cheng <echeng at apple.com>: >> >> On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: >> >>> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >>> Predecessors according to CFG: 0x8fdac90 (#0) >>> %R0<def> = MOVi 0, 14, %reg0,

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

...were swapped by Join, swap them back so > that the > register > 00370 // mapping (in the r2i map) is correct. > 00371 if (Swapped) SrcInt.swap(DstInt); > > Whoops! At this point repSrcReg is not consistent with SrcInt and the > same goes for repDstReg! > > 00372 li_->removeInterval(repSrcReg); > 00373 r2rMap_[repSrcReg] = repDstReg; > > Does this code get us into trouble due to the inconsistency created > above? > > Is this a bug? There's a lot of indirection going on here and it's > hard to > keep track of it. I am n...

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? >

...as that after MergeInClobberRanges that %reg15 > > would contain [458,5168:0 [0]). But it doesn't. > > So this is the call site? > > // Update the liveintervals of sub-registers. > for (const unsigned *AS = tri_->getSubRegisters(DstReg); *AS; ++AS) > li_->getOrCreateInterval(*AS).MergeInClobberRanges(*ResSrcInt, > li_- Yep. > >getVNInfoAllocator()); > > Can you take a look at MergeInClobberRanges() to see what is going on? > Otherwise, please file a bug with a test case. Yes...

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

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

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

...nager knows which analyses to make available + // to coalescing and which analyses coalescing invalidates. + getAnalysis<RegisterCoalescer>().getAnalysisUsage(AU); MachineFunctionPass::getAnalysisUsage(AU); } @@ -194,6 +200,10 @@ mri_ = tm_->getRegisterInfo(); li_ = &getAnalysis<LiveIntervals>(); + RegisterCoalescer &coalescer = getAnalysis<RegisterCoalescer>(); + + coalescer.invoke(fn, *this); + // If this is the first function compiled, compute the related reg classes. if (RelatedRegClasses.empty()) ComputeRelatedRegCla...

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is