search for: def_begin

On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote: > So if this early exit is taken: > > // SSA defs do not have output/anti dependencies. > // The current operand is a def, so we have at least one. > if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) > return; > > we do not ever get to this point: > > VRegDefs.insert(VReg2SUnit(Reg, SU)); > > But later, when checking for anti dependency for another MI here: > > void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { >...

...ScheduleDAGInstrs::addVRegDefDeps(SUnit *SU, unsigned OperIdx) { const MachineInstr *MI = SU->getInstr(); unsigned Reg = MI->getOperand(OperIdx).getReg(); // SSA defs do not have output/anti dependencies. // The current operand is a def, so we have at least one. if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) <<<<<<<<<<<<<<<<<< This is what I am missing. See below. return; // Add output dependence to the next nearest def of this vreg. // // Unless this definition is dead, the output dependence should be // trans...

...ilable somewhere that I've missed? If not, > is there a better way to find all uses of a defined value post register > allocation? Writing a def/use chain pass would not be hard but if the > information is already there I'd rather avoid that cost. :) Do the MachineRegisterInfo::def_begin/def_end/use_begin/use_end iterators not work on physical registers? --Owen

...LVMdev] Assert in live update from MI scheduler. On Jun 13, 2012, at 10:49 AM, Sergei Larin <slarin at codeaurora.org> wrote: So if this early exit is taken: // SSA defs do not have output/anti dependencies. // The current operand is a def, so we have at least one. if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) return; we do not ever get to this point: VRegDefs.insert(VReg2SUnit(Reg, SU)); But later, when checking for anti dependency for another MI here: void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { ... // Add antidependence to the following def of...

Looking through TOT sources, I don't see anything that would provide def/use chains (or equivalent information) post register allocation. I would like to write some peeps to clean up various target-specific things but for safety I will need such information. Is such an analysis pass available somewhere that I've missed? If not, is there a better way to find all uses of a defined value

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

...that I've missed? If not, >> is there a better way to find all uses of a defined value post register >> allocation? Writing a def/use chain pass would not be hard but if the >> information is already there I'd rather avoid that cost. :) > Do the MachineRegisterInfo::def_begin/def_end/use_begin/use_end iterators not work on physical registers? > I seem to recall, the last time I used those, that they ended up being a fairly flat list of all definitions and all uses of a physical registers, not all the uses of a particular definition (or vice versa). -- Joshua Cra...

...issed? If not, >>> is there a better way to find all uses of a defined value post register >>> allocation? Writing a def/use chain pass would not be hard but if the >>> information is already there I'd rather avoid that cost. :) >> Do the MachineRegisterInfo::def_begin/def_end/use_begin/use_end iterators not work on physical registers? >> > > I seem to recall, the last time I used those, that they ended up being a > fairly flat list of all definitions and all uses of a physical > registers, not all the uses of a particular definition (or vic...

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

On Sep 18, 2012, at 1:45 PM, Bjorn De Sutter <bjorn.desutter at elis.ugent.be> wrote: > I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

Hi, I am working on a backend for a CGRA architecture with advanced predicate support (as on EPIC machines and as first used in the OpenIMPACT compiler). Until last month, the backend was working fine, but since the r161643 commit by stoklund, my backend doesn't work anymore. I think I noticed some related commits later on, and the assertion I get on the latest trunk (r164162) differs from

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h