search for: mri_

In LiveIntervals::processImplicitDefs() we have this: for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg), UE = mri_->use_end(); UI != UE; ) { MachineOperand &RMO = UI.getOperand(); MachineInstr *RMI = &*UI; ++UI; MachineBasicBlock *RMBB = RMI->getParent(); if (RMBB == MBB) continue; const TargetRegi...

On Jul 17, 2009, at 7:57 AM, David Greene wrote: > In LiveIntervals::processImplicitDefs() we have this: > > for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg), > UE = mri_->use_end(); UI != UE; ) { > MachineOperand &RMO = UI.getOperand(); > MachineInstr *RMI = &*UI; > ++UI; > MachineBasicBlock *RMBB = RMI->getParent(); > if (RMBB == MBB) > contin...

...src> where src was allocated to register A will make dst be allocated also to A, even when it was defined as not allocatable in .td files. This is due to the checking in RegAllocLinearScan:1004 if (Reg && allocatableRegs_[Reg] && RC->contains(Reg)) mri_->setRegAllocationHint(cur->reg, 0, Reg); where "allocatableRegs_" is calculated during pass init, and ignores register class. I think this should be changed to: if (Reg && (tri_->getAllocatableSet(*mf_, RC))[Reg] && RC- >contains(Reg))...

...SimpleRegisterCoalescing : public MachineFunctionPass { + class RegisterAllocator; + + class SimpleRegisterCoalescing : public MachineFunctionPass, + public RegisterCoalescer { MachineFunction* mf_; const TargetMachine* tm_; const MRegisterInfo* mri_; @@ -45,10 +50,35 @@ /// with other intervals. BitVector JoinedLIs; + /// didWork - Tell whether we have run on this function already. + /// This allows the coalescer to either run independently or from + /// within a register allocator. + typedef std::map<const MachineFu...

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

...> ’t know enough about this specific code to help with this respect. >> >> >> >> My concern was with the users of getModReg(). In your new proposal, >> doing & on the result of getModRef() may yield unexpected results. >> >> E.g., “getModRef() & MRI_MustMod != 0” doesn’t imply that the >> instruction will write because the result might have been MRI_Mod (= >> NoModRef | MustMod). >> >> As long as this fact is properly document, I’m good :) (btw, thanks for >> fixing the documentation of the old MRI_* values; it wa...

...ith a, you can >> actually clone foo here, change it to be pass-by-value, and promote the >> argument inside of it (if you wanted to). >> >> So you can use this info to, for example, do interprocedural promotion. >> >> >>> Are we instead looking to set a MRI_Must bit, disjunct of MRI_Mod, and >>> test for MRI_Ref&MRI_Must or MRI_Mod&MRI_Must? >>> >> >> Yes. >> > > I didn't mean to pick on the example, sorry if that's how it came through. > > Since the consensus is to expose the Must info in...