Difference between revisions of "XCSG:ControlFlow (Edge)"
m (TheodoreMurdock moved page ControlFlow to ControlFlow (Edge)) |
(→Specification) |
||
| Line 2: | Line 2: | ||
{{Edge | {{Edge | ||
| extends = Edge | | extends = Edge | ||
| − | | description = Links [[ | + | | description = Links [[ControlFlow (Node)|Control Flow nodes]] to other ControlFlow nodes that follow them in the program order of a [[Function]] declaration. Multiple edges from the same ControlFlow node indicate branching of control flow. |
| + | | permitted = ControlFlow (Node),ControlFlow (Node),*,* | ||
}} | }} | ||
Revision as of 16:53, 13 May 2014
Specification
| Metaclass | ControlFlow (Edge) |
|---|---|
| Extends | Edge |
| Description | Links Control Flow nodes to other ControlFlow nodes that follow them in the program order of a Function declaration. Multiple edges from the same ControlFlow node indicate branching of control flow. |
| Direct Subkinds | ControlFlowBackEdge |
|---|
| Permitted Connections | ||
|---|---|---|
| Predecessor | Multiplicity | Successor |
| ControlFlow (Node) | ✱ ➞ ✱ | ControlFlow (Node) |
It is worth noting that control flow edges do not guarantee actual order of execution, as both compilers and CPUs are free to re-order the execution of statements that do not have data interdependence, unless some kind of synchronization command is used to prevent such optimizations. While the re-ordering is always equivalent to the original ordering if the program is single-threaded, the re-ordering may be noticed by other threads, or occasionally in otherwise single-threaded programs which access data mutated by other programs or by hardware (if, for example, two requests for the current time were run out-of-order).
However, where questions regarding the ordering of actions that have data interdependence might arise from analyzing data flow alone, the program ordering information from control flow can be used to disambiguate.
