search for: removeinterval

...>> LiveIntervals *LIS = &getAnalysis<LiveIntervals>(); >> 1. LIS->insertMBBInMaps(NewMBB) >> 2. LIS->InsertMachineInstrRangeInMaps(NewMBB->begin(), NewMBB->end()) >> 3. Due to some machine instructions of NewMBB copy from OldMBB, I have to removeInterval firstly. Then I use LIS->createAndComputeVirtRegInterval() to update LiveInterval info of NewMBB. >> 4. Then I want to delete OldMBB in the current MachineFuncion. At the same time, delete LiveIntervals info of OldMBB. So, firstly, Use RemoveMachineInstrFromMaps() to erase SlotIndexes...

...*LIS = &getAnalysis<LiveIntervals>(); >>>> 1. LIS->insertMBBInMaps(NewMBB) >>>> 2. LIS->InsertMachineInstrRangeInMaps(NewMBB->begin(), NewMBB->end()) >>>> 3. Due to some machine instructions of NewMBB copy from OldMBB, I have to removeInterval firstly. Then I use LIS->createAndComputeVirtRegInterval() to update LiveInterval info of NewMBB. >>>> 4. Then I want to delete OldMBB in the current MachineFuncion. At the same time, delete LiveIntervals info of OldMBB. So, firstly, Use RemoveMachineInstrFromMaps() to erase Slot...

.... [...] 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. -Dave

Hi, I am working on a simple copy propagation pass for the R600 backend that propagates immediates rather than registers. For example, I want to transform: ... %vreg1 = V_MOV_B32 1 %vreg2 = V_ADD_I32 %vreg1, %vreg0 ... into: %vreg1 = V_MOV_B32 1 ; <- Only delete this if it is dead %vreg2 = V_ADD_I32 1, %vreg0 For best results, I am trying to run this pass after the TwoAddressInstruction

...apped 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 not sure. I will pok...

...y update steps are shown following: LiveIntervals *LIS = &getAnalysis<LiveIntervals>(); 1. LIS->insertMBBInMaps(NewMBB) 2. LIS->InsertMachineInstrRangeInMaps(NewMBB->begin(), NewMBB->end()) 3. Due to some machine instructions of NewMBB copy from OldMBB, I have to removeInterval firstly. Then I use LIS->createAndComputeVirtRegInterval() to update LiveInterval info of NewMBB. 4. Then I want to delete OldMBB in the current MachineFuncion. At the same time, delete LiveIntervals info of OldMBB. So, firstly, Use RemoveMachineInstrFromMaps() to erase SlotIndexes info of O...

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

Hi, I insert a new machine basic block(MBB) before Greedy Register Allocation, after Simple Register Coalescing. But I encounter a fatal error "regalloc = ... not currently supported with -O0". I use command line with opt level O2, not O0. The probable reason of this error is that no LiveInterval information for newly MBB which is used by Register Allocation. And, LiveIntervals depend