search for: addpred

Andy, et al., In ScheduleDAGInstrs::buildSchedGraph, the code for handling stores has this: if (!ExitSU.isPred(SU)) // Push store's up a bit to avoid them getting in between cmp // and branches. ExitSU.addPred(SDep(SU, SDep::Artificial)); This code does not seem to be in any way specific to compares; and in any case, at least on the PPC A2, scheduling stores in between the compare and the branch would not be a bad thing (because the core is in order, and the compare has a 2-cycle latency, so if there is...

...no dependency to SU1 and *neither to SU2*. The AliasChain concept is bypassed. I don't understand how it can first be assumed that an SU becomes AliasChain, and then an SU with lower NodeNum that may alias is allowed to skip its dep to the AliasChain? The BarrierChain is never skipped because addPred() is called directly, and I don't see how it is safe to skip the AliasChain for aliasing SUs, I think it should always be added? In other words, it may be that SU0 has a dep towards SU2 in the example, but not towards SU1, so therefore it is not safe to skip this dep. Calling addPred() instead...

...t;> Andy, et al., >> >> In ScheduleDAGInstrs::buildSchedGraph, the code for handling stores has this: >> >> if (!ExitSU.isPred(SU)) >> // Push store's up a bit to avoid them getting in between cmp >> // and branches. >> ExitSU.addPred(SDep(SU, SDep::Artificial)); >> >> This code does not seem to be in any way specific to compares; and in any case, at least on the PPC A2, scheduling stores in between the compare and the branch would not be a bad thing (because the core is in order, and the compare has a 2-cycle laten...

...RegDefs.insert(VReg2SUnit(Reg, SU)); else { SUnit *DefSU = DefI->SU; if (DefSU != SU && DefSU != &ExitSU) { unsigned OutLatency = TII->getOutputLatency(InstrItins, MI, OperIdx, DefSU->getInstr()); DefSU->addPred(SDep(SU, SDep::Output, OutLatency, Reg)); } DefI->SU = SU; } } 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...

...y you figured out how to debug it. I'm not sure if you're using the MachineScheduler pass or PostRAScheduler. For MachineScheduler, use -view-misched-dags and -debug-only=misched. For PostRA: -debug-only=post-RA-sched. Modifying the DAG edges is tricky to get right. But removePred() and addPred() are the basic primitives... -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130308/6050b928/attachment.html>

Hi, I am trying to add Hazard scheduling nodes after buildSchedGraph(), with a scheduler derived from ScheduleDAGInstrs. I get weird errors, so I wonder what I am doing wrong? What I am doing right now is: I have a created MI with opcode HAZARD that does not have parent, and I greate a SUnit(HazardMI). I use this one HazardMI for all hazard nodes. I remove all edges using removePred. I insert

...> void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { > ... > // Add antidependence to the following def of the vreg it uses. > VReg2SUnitMap::iterator DefI = VRegDefs.find(Reg); > if (DefI != VRegDefs.end() && DefI->SU != SU) > DefI->SU->addPred(SDep(SU, SDep::Anti, 0, Reg)); > > We will never find that def in VRegDefs.find(Reg) even though it exists. > > I know this has been working for a while, but I am still missing something > here. > What is this statement > > if (llvm::next(MRI.def_begin(Reg)) == MRI.def_e...

...concept is > bypassed. > > > > I don’t understand how it can first be assumed that an SU becomes > AliasChain, and then an SU > > with lower NodeNum that may alias is allowed to skip its dep to the > AliasChain? > > The BarrierChain is never skipped because addPred() is called > directly, and I don’t see how it is > > safe to skip the AliasChain for aliasing SUs, I think it should always > be added? In other words, > > it may be that SU0 has a dep towards SU2 in the example, but not > towards SU1, so therefore it > > is not sa...

...ly you figured out how to debug it. I'm not sure if you're using the MachineScheduler pass or PostRAScheduler. For MachineScheduler, use -view-misched-dags and -debug-only=misched. For PostRA: -debug-only=post-RA-sched. Modifying the DAG edges is tricky to get right. But removePred() and addPred() are the basic primitives... -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130312/af11ba1f/attachment.html>

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;

...t;> >> >> I don’t understand how it can first be assumed that an SU becomes >> AliasChain, and then an SU >> >> with lower NodeNum that may alias is allowed to skip its dep to the >> AliasChain? >> >> The BarrierChain is never skipped because addPred() is called >> directly, and I don’t see how it is >> >> safe to skip the AliasChain for aliasing SUs, I think it should >> always be added? In other words, >> >> it may be that SU0 has a dep towards SU2 in the example, but not >> towards SU1, so there...

...ependency for another MI here: void ScheduleDAGInstrs::addVRegUseDeps(SUnit *SU, unsigned OperIdx) { ... // Add antidependence to the following def of the vreg it uses. VReg2SUnitMap::iterator DefI = VRegDefs.find(Reg); if (DefI != VRegDefs.end() && DefI->SU != SU) DefI->SU->addPred(SDep(SU, SDep::Anti, 0, Reg)); We will never find that def in VRegDefs.find(Reg) even though it exists. I know this has been working for a while, but I am still missing something here. What is this statement if (llvm::next(MRI.def_begin(Reg)) == MRI.def_end()) should guarantee? From it there m...

...+ hours here without completing, so it looks very much like an endless loop. The processes are using 15, 22 and 27 GB of memory but do not appear to grow further. This worked fine in the past, so appears to be a regression. These stacks seem to be prevalent: #0 0x0000000001850588 in llvm::SUnit::addPred(llvm::SDep const&, bool) () #1 0x0000000001855265 in llvm::ScheduleDAGInstrs::addChainDependency(llvm::SUnit*, llvm::SUnit*, unsigned int) () #2 0x0000000001855519 in llvm::ScheduleDAGInstrs::addChainDependencies(llvm::SUnit*, llvm::ScheduleDAGInstrs::Value2SUsMap&) () #3 0x000000000185f...

...9;s scheduling.) I had been thinking that the minimal changes approach would be by attaching the desired ordering to the bit-code as metadata nodes, using the standard JIT interface and just adding a tiny bit of code in the scheduler to recognise the metadata and add those as extra dependencies via addPred(). However, looking at things in detail it looks like instruction selection does things that would make propagating bitcode-instruction ordering through to MachineInstr ordering actually pretty invasive. It looks like it may actually be less invasive overall to put the "try different ordering...