// General description of instruction scheduling. // // This pass tries to improve the quality of the generated code by reordering // instructions in the graph to avoid execution delays caused by execution // dependencies. // Currently, scheduling is performed at the block level, so no `HInstruction` // ever leaves its block in this pass. // // The scheduling process iterates through blocks in the graph. For blocks that // we can and want to schedule: // 1) Build a dependency graph for instructions. // It includes data dependencies (inputs/uses), but also environment // dependencies and side-effect dependencies. // 2) Schedule the dependency graph. // This is a topological sort of the dependency graph, using heuristics to // decide what node to scheduler first when there are multiple candidates. // // A few factors impacting the quality of the scheduling are: // - The heuristics used to decide what node to schedule in the topological sort // when there are multiple valid candidates. There is a wide range of // complexity possible here, going from a simple model only considering // latencies, to a super detailed CPU pipeline model. // - Fewer dependencies in the dependency graph give more freedom for the // scheduling heuristics. For example de-aliasing can allow possibilities for // reordering of memory accesses. // - The level of abstraction of the IR. It is easier to evaluate scheduling for // IRs that translate to a single assembly instruction than for IRs // that generate multiple assembly instructions or generate different code // depending on properties of the IR. // - Scheduling is performed before register allocation, it is not aware of the // impact of moving instructions on register allocation. // // // The scheduling code uses the terms predecessors, successors, and dependencies. // This can be confusing at times, so here are clarifications. // These terms are used from the point of view of the program dependency graph. So // the inputs of an instruction are part of its dependencies, and hence part its // predecessors. So the uses of an instruction are (part of) its successors. // (Side-effect dependencies can yield predecessors or successors that are not // inputs or uses.) // // Here is a trivial example. For the Java code: // // int a = 1 + 2; // // we would have the instructions // // i1 HIntConstant 1 // i2 HIntConstant 2 // i3 HAdd [i1,i2] // // `i1` and `i2` are predecessors of `i3`. // `i3` is a successor of `i1` and a successor of `i2`. // In a scheduling graph for this code we would have three nodes `n1`, `n2`, // and `n3` (respectively for instructions `i1`, `i1`, and `i3`). // Conceptually the program dependency graph for this would contain two edges // // n1 -> n3 // n2 -> n3 // // Since we schedule backwards (starting from the last instruction in each basic // block), the implementation of nodes keeps a list of pointers their // predecessors. So `n3` would keep pointers to its predecessors `n1` and `n2`. // // Node dependencies are also referred to from the program dependency graph // point of view: we say that node `B` immediately depends on `A` if there is an // edge from `A` to `B` in the program dependency graph. `A` is a predecessor of // `B`, `B` is a successor of `A`. In the example above `n3` depends on `n1` and // `n2`. // Since nodes in the scheduling graph keep a list of their predecessors, node // `B` will have a pointer to its predecessor `A`. // As we schedule backwards, `B` will be selected for scheduling before `A` is. // // So the scheduling for the example above could happen as follow // // |---------------------------+------------------------| // | candidates for scheduling | instructions scheduled | // | --------------------------+------------------------| // // The only node without successors is `n3`, so it is the only initial // candidate. // // | n3 | (none) | // // We schedule `n3` as the last (and only) instruction. All its predecessors // that do not have any unscheduled successors become candidate. That is, `n1` // and `n2` become candidates. // // | n1, n2 | n3 | // // One of the candidates is selected. In practice this is where scheduling // heuristics kick in, to decide which of the candidates should be selected. // In this example, let it be `n1`. It is scheduled before previously scheduled // nodes (in program order). There are no other nodes to add to the list of // candidates. // // | n2 | n1 | // | | n3 | // // The only candidate available for scheduling is `n2`. Schedule it before // (in program order) the previously scheduled nodes. // // | (none) | n2 | // | | n1 | // | | n3 | // |---------------------------+------------------------| // // So finally the instructions will be executed in the order `i2`, `i1`, and `i3`. // In this trivial example, it does not matter which of `i1` and `i2` is // scheduled first since they are constants. However the same process would // apply if `i1` and `i2` were actual operations (for example `HMul` and `HDiv`).
// Set to true to have instruction scheduling dump scheduling graphs to the file // `scheduling_graphs.dot`. See `SchedulingGraph::DumpAsDotGraph()`. static constexpr bool kDumpDotSchedulingGraphs = false;
// Typically used as a default instruction latency. static constexpr uint32_t kGenericInstructionLatency = 1;
void AddOtherPredecessor(SchedulingNode* predecessor) { // Check whether the predecessor has been added earlier. // As an optimization of the scheduling graph, we don't need to create another dependency if // there is a data dependency between scheduling nodes. if (HasOtherDependency(predecessor) || HasDataDependency(predecessor)) { return;
}
other_predecessors_.push_back(predecessor);
predecessor->num_unscheduled_successors_++;
}
private: // The latency of this node. It represents the latency between the moment the // last instruction for this node has executed to the moment the result // produced by this node is available to users.
uint32_t latency_; // This represents the time spent *within* the generated code for this node. // It should be zero for nodes that only generate a single instruction.
uint32_t internal_latency_;
// The critical path from this instruction to the end of scheduling. It is // used by the scheduling heuristics to measure the priority of this instruction. // It is defined as // critical_path_ = latency_ + max((use.internal_latency_ + use.critical_path_) for all uses) // (Note that here 'uses' is equivalent to 'data successors'. Also see comments in // `HScheduler::Schedule(SchedulingNode* scheduling_node)`).
uint32_t critical_path_;
// The instruction that this node represents.
HInstruction* const instruction_;
// If a node is scheduling barrier, other nodes cannot be scheduled before it. constbool is_scheduling_barrier_;
// The lists of predecessors. They cannot be scheduled before this node. Once // this node is scheduled, we check whether any of its predecessors has become a // valid candidate for scheduling. // Predecessors in `data_predecessors_` are data dependencies. Those in // `other_predecessors_` contain side-effect dependencies, environment // dependencies, and scheduling barrier dependencies.
ScopedArenaVector<SchedulingNode*> data_predecessors_;
ScopedArenaVector<SchedulingNode*> other_predecessors_;
// The number of unscheduled successors for this node. This number is // decremented as successors are scheduled. When it reaches zero this node // becomes a valid candidate to schedule.
uint32_t num_unscheduled_successors_;
// Even if above memory dependency check has passed, it is still necessary to // check dependencies between instructions that can throw and instructions // that write to memory. if (HasExceptionDependency(instr1, instr2)) { returntrue;
}
SchedulingNode* GetNode(const HInstruction* instr) const { auto it = nodes_map_.find(instr); if (it == nodes_map_.end()) { return nullptr;
} else { return it->second.get();
}
}
size_t Size() const { return nodes_map_.size();
}
// Dump the scheduling graph, in dot file format, appending it to the file // `scheduling_graphs.dot`. void DumpAsDotGraph(const std::string& description, const ScopedArenaVector<SchedulingNode*>& initial_candidates);
// Analyze whether the scheduling node has cross-iteration dependencies which mean it uses // values defined on the previous iteration. // // Supported cases: // // L: // v2 = loop_head_phi(v1) // instr1(v2) // v1 = instr2 // goto L // // In such cases moving instr2 before instr1 creates intersecting live ranges // of v1 and v2. As a result a separate register is needed to keep the value // defined by instr2 which is only used on the next iteration. // If instr2 is not moved, no additional register is needed. The register // used by instr1 is reused. // To prevent such a situation a "other" dependency between instr1 and instr2 must be set. void AddCrossIterationDependencies(SchedulingNode* node);
// Add dependencies nodes for the given `SchedulingNode`: inputs, environments, and side-effects. void AddDependencies(SchedulingNode* node, bool is_scheduling_barrier = false);
/* *Thevisitorsderivedfromthisbaseclassareusedbyschedulerstoevaluate *thelatenciesof`HInstruction`s.
*/ template <typename T> class SchedulingLatencyVisitor : public CRTPGraphVisitor<T> { public: // This class and its sub-classes will never be used to drive a visit of an // `HGraph` but only to visit `HInstructions` one at a time, so we do not need // to pass a valid graph to `CRTPGraphVisitor<T>()`.
SchedulingLatencyVisitor()
: CRTPGraphVisitor<T>(nullptr),
last_visited_latency_(0),
last_visited_internal_latency_(0) {}
void CalculateLatency(SchedulingNode* node) { // By default nodes have no internal latency.
last_visited_internal_latency_ = 0; this->Dispatch(node->GetInstruction());
}
protected: // The latency of the most recent visited SchedulingNode. // This is for reporting the latency value to the user of this visitor.
uint32_t last_visited_latency_; // This represents the time spent *within* the generated code for the most recent visited // SchedulingNode. This is for reporting the internal latency value to the user of this visitor.
uint32_t last_visited_internal_latency_;
private: // Hide `VisitInstruction()` from `CRTPGraphVisitor<>` with a deleted function. // Architecture-specific scheduling latency visitors must handle all instructions // (potentially by implementing their own generic `VisitInstruction()`. void VisitInstruction(HInstruction* instruction) = delete;
};
// Any instruction returning `false` via this method will prevent its // containing basic block from being scheduled. // This method is used to restrict scheduling to instructions that we know are // safe to handle. // // For newly introduced instructions by default HScheduler::IsSchedulable returns false. // HScheduler${ARCH}::IsSchedulable can be overridden to return true for an instruction (see // scheduler_arm64.h for example) if it is safe to schedule it; in this case one *must* also // look at/update HScheduler${ARCH}::IsSchedulingBarrier for this instruction. virtualbool IsSchedulable(const HInstruction* instruction) const; bool IsSchedulable(const HBasicBlock* block) const;
Die Informationen auf dieser Webseite wurden
nach bestem Wissen sorgfältig zusammengestellt. Es wird jedoch weder Vollständigkeit, noch Richtigkeit,
noch Qualität der bereit gestellten Informationen zugesichert.
Bemerkung:
Die farbliche Syntaxdarstellung und die Messung sind noch experimentell.