search for: exitsu

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

...at 4:03 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 17, 2014, at 3:54 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> 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...

...like to instead ask another question: Why is I->isCtrl() used in code like // Iterate over chain dependencies only. for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb->Succs.end(); I != E; ++I) if (I->isCtrl()) iterateChainSucc (AA, MFI, SUa, I->getSUnit(), ExitSU, Depth, Visited); ? I thought only chain edges are relevant, and would instead use if (J->getKind() == SDep::Order) I got strange edges, from memory accesses to normal operation instructions that do not touch memory, because also anti and output edges are followed. Best regards, Jonas Pauls...

...branches, calls, and other strange barriers. Instructions can be reordered between the boundaries during schedule(), and the bundler can operate across regions via exitRegion() and finishBlock(). You will still have DAG edges from the instruction that a branch depends on to the branch (captured by ExitSU), but you won't have any DAG edges crossing the boundary. 2) Scheduler and bundler operate on the same scope (an entire block): isSchedulingBoundary = false and all instructions must be correctly handled by the DAG builder. DAG edges will be built for all instructions within the block. --- No...

...: > > Why is I->isCtrl() used in code like > > // Iterate over chain dependencies only. > for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E = SUb->Succs.end(); > I != E; ++I) > if (I->isCtrl()) > iterateChainSucc (AA, MFI, SUa, I->getSUnit(), ExitSU, Depth, > Visited); > > ? > > I thought only chain edges are relevant, and would instead use if > (J->getKind() == SDep::Order) > > I got strange edges, from memory accesses to normal operation instructions that do not touch memory, because also anti and output edges...

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

...branches, calls, and other strange barriers. Instructions can be reordered between the boundaries during schedule(), and the bundler can operate across regions via exitRegion() and finishBlock(). You will still have DAG edges from the instruction that a branch depends on to the branch (captured by ExitSU), but you won't have any DAG edges crossing the boundary. > > 2) Scheduler and bundler operate on the same scope (an entire block): isSchedulingBoundary = false and all instructions must be correctly handled by the DAG builder. DAG edges will be built for all instructions within the bloc...

...he output dependence edge // is also useful if output latency exceeds def-use latency. VReg2SUnitMap::iterator DefI = VRegDefs.find(Reg); if (DefI == VRegDefs.end()) VRegDefs.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 de...

...mptions in common code. > 2) If above is true, can SUnit node in SchedDAG (constructed by > ScheduleDAGInstrs::BuildSchedGraph) be "dangling" - not having successors > (and/or predecessor)? (see example below). Yes. The DAG can have multiple roots/leaves. We have special Entry/ExitSU that partially model latency of data flow across blocks and into call arguments, but they really only exist as a heuristic. > The reason I keep on asking this - both back ends we support (Hexagon and > ARM) are happily optimizing out fall-through branches away by the time BB > gets to the...

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;