search for: getinstructionfromindex

...r the bundle, but then the verifier pukes on it and says that there is a use of the register after it's dead. The dead-marking on the BUNDLE is introduced by LiveIntervals::computeDeadValues which does // This is a dead def. Make sure the instruction knows. MachineInstr *MI = getInstructionFromIndex(Def); assert(MI && "No instruction defining live value"); MI->addRegisterDead(LI.reg, TRI); and the reload after the BUNDLE is introduced by InlineSpiller::spillAroundUses which has determined that the register is live: // Rewrite instruction operands....

...ntinue; //If not constant then check its def if(depth > 6) return false; LiveInterval &li = LIS.getInterval(MO.getReg()); SlotIndex UseIdx = LIS.getInstructionIndex(*DefMI); VNInfo *UseVNInfo = li.getVNInfoAt(UseIdx); MachineInstr *NewDefMI = LIS.getInstructionFromIndex(UseVNInfo->def); if(!checkComplexRematerializable(UseVNInfo, NewDefMI, depth+1, aa)) return false; } } Remattable.insert(VNI); //May have to add new data structure return true; } In above function we are calling a new function TII.isReMaterializablePossible(*DefMI, a...

...pukes on it and says that there is a use of the register after it's dead. >> >> The dead-marking on the BUNDLE is introduced by LiveIntervals::computeDeadValues which does >> >> // This is a dead def. Make sure the instruction knows. >> MachineInstr *MI = getInstructionFromIndex(Def); >> assert(MI && "No instruction defining live value"); >> MI->addRegisterDead(LI.reg, TRI); > > I think the actual problem here is that MachineInstr::addRegisterDead only works on a single instruction and not on the whole bundle. > > - M...

Hi Roman, > I already started work on the implementation of this algorithm and have > a few hopefully rather simple questions: > > 1) What is the easiest way to understand which MBB a given instruction > index belongs to? All the required information is available in the > MBB2IdxMap of the LiveIntervalAnalysis class. Would it be useful to add > a small function

Hi, I'm trying to sketch an LLVM-based implementation of the Extended Linear Scan algorithm, described in this Vivek Sarkar's paper: http://www.cs.rice.edu/~vs3/PDF/cc2007.pdf Sarkar reports that this version of Linear Scan produces better code than graph-coloring regallocs and is also much faster (15x to 68x). I already started work on the implementation of this algorithm and have a few