search for: predsu

Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- | --------- | | | Setup ^ | When there are two successors of PredSU with type getCallFrameDestroyOpcode and there is order bet...

...heduleBottomUp() ??? Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- | --------- | | | Setup ^ | When there are two successors of PredSU with type getCallFrameDestroyOpcode and there is order bet...

Here is a bit more data. After PrescheduleNodesWithMultipleUses has been run, the following Predecessor/Successor links are 'dumpAll'ed. (I attach the full dumpAll before & after "Prescheduling SU #7 next to PredSU #4 to guide scheduling in the presence of multiple uses") SU(3) Predecessors: val SU(5): Latency=1 ch SU(7): Latency=1 val SU(7): Latency=1 SU(7): ch SU(3): Latency=1 val SU(3): Latency=1 val SU(5): Latency=1 It looks odd but seems to be fine as all nodes are capable o...

Hi I have brought everything together in this email. The problem ======== Take the following DAG (arrow to predecessor): SetUp2 SetUp1 ^ ^ | | | | Destroy2---->PredSU <----SU ^ ^ ^ | | | | | | ----------- | --------- | | | Destroy1 ^ | In this example there are two successors of 'PredSU' with type getCallFrameDestroyOpcode...

Hi, I have an assert firing due to PickNodeToScheduleBottomUp(): 1. having a CallResource in use pushing an interference of current SUnit. 2. having no more SUnits in the AvailableQueue 3. The only interference being the SUnit that just failed due to a Call Resource. 4. An attempt to duplicate this node which has the 'Call Resource' as a physical register. Thus the call

...@@ void RegReductionPQBase::PrescheduleNodesWithMultipleUses() { continue; // Avoid prescheduling to copies from virtual registers, which don't behave // like other nodes from the perspective of scheduling heuristics. - if (SDNode *N = SU->getNode()) + if (SDNode *N = PredSU->getNode()) if (N->getOpcode() == ISD::CopyFromReg && TargetRegisterInfo::isVirtualRegister (cast<RegisterSDNode>(N->getOperand(1))->getReg())) ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists...

...operator() > will return the result of BUCompareLatency. That function first checks > for stalls and returns 1 or -1. Only after that does it look at the > relative latencies. Looking at this more carefully, I think that I see the problem. The heights are set to account for the latencies: PredSU->setHeightToAtLeast(SU->getHeight() + PredEdge->getLatency()); but the latencies are considered only if the node as an ILP scheduling preference (the default in TargetLowering.h is None): bool LStall = (!checkPref || left->SchedulingPref == Sched::ILP) && BUHasStall(left,...

...the result of BUCompareLatency. That function first checks >> for stalls and returns 1 or -1. Only after that does it look at the >> relative latencies. > > Looking at this more carefully, I think that I see the problem. The > heights are set to account for the latencies: > PredSU->setHeightToAtLeast(SU->getHeight() + PredEdge->getLatency()); > > but the latencies are considered only if the node as an ILP scheduling > preference (the default in TargetLowering.h is None): > bool LStall = (!checkPref || left->SchedulingPref == Sched::ILP) && &...

On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > load-fadd-store chains to schedule. A store takes two cycles to > > clear > > its last pipeline stage. The fadd takes longer to compute its result > > (say 5