similar to: [LLVMdev] slot-indexes, liveranges...

Andy, Jacob, I have ported Hexagon MI scheduler to use the new scheduler infrastructure, but one of my tests triggers an assert in LiveInterval update. On the surface it does not make much sense to me, so I wonder if this is something you readily recognize, before I try to prop it open... The assert is: lib/CodeGen/LiveInterval.cpp:266: llvm::LiveRange*

On Thursday 17 January 2008 13:03, Evan Cheng wrote: > > So why does the live range extend throughout the entire basic block? > > > > %reg1055 doesn't appear anywhere else in the program so it shouldn't > > be > > live-in to the block. > > It could be a bug. Can you get me a test case? I'll see if I can whittle it down. It's a pretty huge

Andy, I've described that issue (see below) when you were out of town... I think I am getting more context on it. Please take a look... So, in short, when the new MI scheduler performs move of an instruction, it does something like this: // Move the instruction to its new location in the instruction stream. MachineInstr *MI = SU->getInstr(); if (IsTopNode) {

On Jan 16, 2008, at 11:49 AM, David Greene wrote: > I had been assuming that give a LiveRange a, a.valno->def, if > valid, would be the same as a.start. But this is apparently not > always the case. For example: > > Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) > 308 %reg1051 = MOV64rr %reg1227<kill> > 312 %reg1052 = MOV64rr %reg1228<kill>

I had been assuming that give a LiveRange a, a.valno->def, if valid, would be the same as a.start. But this is apparently not always the case. For example: Predecessors according to CFG: 0x839d130 (#3) 0x8462780 (#35) 308 %reg1051 = MOV64rr %reg1227<kill> 312 %reg1052 = MOV64rr %reg1228<kill> 316 %reg1053 = MOV64rr %reg1229<kill> 320 %reg1054 = MOV64rr

Hi, thank you for your explanations. In order to get a pre-RA scheduling, I would need something like: - LiveVars - PhiElim - TwoAddr - LiveIntervals - Coalescing - Scheduler (new) - SlotIndexing - LiveIntervals2 (new) - RegAllocMy qeustion then is, is it really so difficult to create the live intervals information, with modifications to the original algorithm, or even from scratch?

Hello, I'm getting an assertion in register allocator, specifically in LiveIntervalAnalysis.h, method LiveIntervals::getInstructionIndex: unsigned getInstructionIndex(MachineInstr* instr) const { Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); assert(it != mi2iMap_.end() && "Invalid instruction!"); return it->second; } The crash happens

On May 24, 2011, at 8:22 AM, Jonas Paulsson wrote: > Hi (Jakob), > > in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass > prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's > per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a

Hrm, I see a bug here. Let's say the liverange in question is [13,20) and the interval it's being merged to is something like this: [1, 4), [10, 15) IP = std::upper_bound(IP, end(), Start); if (IP != begin() && IP[-1].end > Start) { if (IP->valno != LHSValNo) { ReplacedValNos.push_back(IP->valno); IP->valno = LHSValNo; //

On Wednesday 30 January 2008 15:06, Evan Cheng wrote: > Hrm, I see a bug here. Let's say the liverange in question is [13,20) > and the interval it's being merged to is something like this: [1, 4), > [10, 15) > > IP = std::upper_bound(IP, end(), Start); > if (IP != begin() && IP[-1].end > Start) { > if (IP->valno != LHSValNo) { >

I am looking for the slot index of a register around the given slot index Min. Is there a better way than the linear search: ... findDefUsesAroundIndex( LiveInterval* li, SlotIndex Min ) ... for( MachineOperand * mo = MRI->getRegUseDefListHead(li->reg); mo; mo = mo->getNextOperandForReg() ) { SlotIndex si = SI->getInstructionIndex( use.getOperand().getParent() ); if(

Hi all, I'm tracking down a register allocation problem and I'm trying to understand this piece of code in InlineSpiller::spillAroundUses: // Find the slot index where this instruction reads and writes OldLI. // This is usually the def slot, except for tied early clobbers. SlotIndex Idx = LIS.getInstructionIndex(*MI).getRegSlot(); if (VNInfo *VNI =

I just ran into a problem here. I'm in SimpleRegisterCoalescing at the point where EXTRACT_SUBREG coalescing updates live ranges of aliased registers (around line 473 of SimpleRegisterCoalescing.cpp). There's a call to MergeValueInAsValue at line 50. MergeValueInAsValue has this code: void LiveInterval::MergeValueInAsValue(const LiveInterval &RHS,

Hi (Jakob), in reference to the prior message below, I have the following follow-up questions, as I also need a scheduling pass prior to regalloc. I need to do this in order to set VLIW-flags, so that the RA is aware of several MI's per cycle with a redefined LiveRange::overlap-function. On a multiple-issue cycle, a register that gets killed can be reused by another MI - these live ranges do

On Jan 30, 2008, at 1:21 PM, David Greene wrote: > On Wednesday 30 January 2008 15:06, Evan Cheng wrote: >> Hrm, I see a bug here. Let's say the liverange in question is [13,20) >> and the interval it's being merged to is something like this: [1, 4), >> [10, 15) >> >> IP = std::upper_bound(IP, end(), Start); >> if (IP != begin() &&

AFAIK std::upper_bound() would not return end(), right? Evan On Jan 29, 2008, at 3:08 PM, David Greene wrote: > I just ran into a problem here. I'm in SimpleRegisterCoalescing at > the point > where EXTRACT_SUBREG coalescing updates live ranges of aliased > registers (around line 473 of SimpleRegisterCoalescing.cpp). > > There's a call to MergeValueInAsValue at line

I've hit a bug in a refactored version of coalescing and I'm trying to understand what is going on. In particular, I'm curious about this line in SimpleRegisterCoalescing.cpp: 00710 LHSValsDefinedFromRHS[VNI] = RHS.getLiveRangeContaining(VNI->def-1)->valno; Why VNI->def-1? The bug I'm seeing is that RHS returns a NULL LiveRange because it doesn't contain

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

Hi Sergei, I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a

On Tuesday 25 September 2007 10:49, David Greene wrote: > I've hit a bug in a refactored version of coalescing and I'm trying to > understand what is going on. In particular, I'm curious about this > line in SimpleRegisterCoalescing.cpp: > > 00710 LHSValsDefinedFromRHS[VNI] = > RHS.getLiveRangeContaining(VNI->def-1)->valno; > > Why VNI->def-1?