Lines Matching refs:edges

19 represent basic blocks and edges represent possible transfer of
40 * Edges::                  Types of edges and their representation.
190 type point to type-safe vectors of edges to the predecessors and
194 When walking the edges in an edge vector, @dfn{edge iterators} should
202 first edge in a vector of edges.
206 last edge in a vector of edges.
238 the edges in a sequence of predecessor or successor edges.  It must
260 several other reasons why edges may be created.  The @code{flags}
267 No type flags are set for edges corresponding to jump instructions.
268 These edges are used for unconditional or conditional jumps and in
274 Fall-thru edges are present in case where the basic block may continue
275 execution to the following one without branching.  These edges have
276 the @code{EDGE_FALLTHRU} flag set.  Unlike other types of edges, these
277 edges must come into the basic block immediately following in the
285 Exception handling edges represent possible control transfers from a
291 edges have the @code{EDGE_ABNORMAL} and @code{EDGE_EH} flags set.
297 anyway.  The edges can be eliminated via @code{purge_dead_edges} call.
319 These edges only exist in the RTL representation.
324 Computed jumps contain edges to all labels in the function referenced
325 from the code.  All those edges have @code{EDGE_ABNORMAL} flag set.
326 The edges used to represent computed jumps often cause compile time
329 these edges need to be handled with special care.  During the earlier
402 return instructions that are represented by edges with no flags set.
423 of executions of basic blocks and edges back to the compiler while
595 the flow of control, possibly eliminating some edges.  This may for
597 unconditional jump.  Updating of edges
601 superfluous edges, if any.
605 this is best modeled as redirection of edges in the control flow graph
625 For a global optimizer, a common operation is to split edges in the