search for: def_end

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 anti...

...VRegDefDeps(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 // transitively redundant wit...

...ewhere 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

...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 the vreg it uses. V...

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;

...9;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 Cranmer New...

...e ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) == def_end()) && "getVRegDef assumes a single definition or no definition"' failed. The code in lib\CodeGen\MachineRegisterInfo.cpp has information about the virtual register's sub-register been written, but that info is not propagated to getVRegDef. Is it possible/ is there...

...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)...

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 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

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, >> >> >>