Techniques for converting control flow programs to data flow programs using control dependence graphs

Abstract

An apparatus for automatically converting a control-flow program into a data-flow program includes a non-transitory machine-readable medium and a translator stored in the machine-readable medium. The translator, when executed by a data processing system, enables the data processing system to (a) automatically generate a control dependence graph of the control-flow program, (b) automatically generate a data-flow graph based at least in part on the control dependence graph, and (c) automatically generate a data-flow program based at least in part on the data-flow graph. In one embodiment or scenario, in response to determining that a variable of the control-flow program is defined in one control dependence region and used in a different control dependence region, the translator can also automatically insert a switch instruction into the data-flow program. Other embodiments are described and claimed.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to techniques for converting computer programs from one architecture to another. In particular, the present disclosure relates to methods and apparatus for automatically converting control flow programs to data flow programs using control dependence graphs. BACKGROUND

[0002] A data processing system (DPS) can include hardware and software components. The hardware components can include a processor, a random access memory (RAM), and a non-volatile storage device (NVS). The software components can include many different kinds of computer programs. The DPS can run the software components by copying them from the NVS to the RAM and then executing them on the processor.

[0003] A processor can be described in terms of its design architecture as well as in terms of its instruction set architecture (ISA). Conventional processors typically adhere to a von Neumann architecture, a Harvard architecture, a modified Harvard architecture, or a similar architecture. According to any such architecture, the design architecture for a processor or processing unit can include an arithmetic logic unit and a control unit, where the control unit contains a program counter. To begin execution of a program, the address of the first instruction in the program is loaded into the program counter. The processor then fetches the instruction at that address, executes the instruction, and increments the program counter to point to the next sequential instruction in the program. The processor can repeat this fetch cycle until the last instruction of the program has been executed. However, a program can use control transfer instructions (e.g., branch instructions) to change the sequence of execution. Control transfer instructions can also be referred to as "control flow instructions." For example, a branch instruction (or another control flow instruction) can cause the processor to replace the contents of the program counter with the address of an instruction other than the next sequential instruction. Additionally, a control flow instruction can modify the program counter conditionally upon the truth of some predicate (e.g., branch if the content of a specified register does not equal zero). Thus, a program can execute different sequences of instructions under different conditions. Some common control flow instructions include conditional instructions (e.g., if then else) and loop instructions (e.g., for, while).

[0004] For the purposes of this disclosure, computer instructions used to directly control or alter the flow of control may be referred to as “control flow instructions.” Many different languages ​​provide many different kinds of control flow instructions. A small sample of control flow instructions includes, but is not limited to, instructions such as (a) if then else, (b) for, (c) while, (d) branch, and (e) branch if equal.

[0005] Similarly, a computer language that includes control flow instructions can be called a "control flow language," and a computer program implemented or written in a control flow language can be called a "control flow program." Likewise, a processor that supports one or more control flow languages ​​or programs can be called a "control flow processor" and is said to have a "control flow architecture." Attached Figure Description

[0006] Figure 1 This is a block diagram of an exemplary embodiment of a data processing system having components including a data stream processor and a data stream converter.

[0007] Figure 2 It is a block diagram of an exemplary embodiment having various diagrams used by a data stream converter to convert a control flow program into a data flow program.

[0008] Figure 3 A flowchart of an exemplary embodiment of the process for generating a control dependency graph is presented.

[0009] Figure 4 A flowchart illustrating an exemplary embodiment of the process for identifying control-dependent regions is presented.

[0010] Figure 5 A flowchart illustrating an exemplary embodiment of the process for generating a data flow graph is presented.

[0011] Figure 6 An exemplary embodiment of a data flow graph is presented.

[0012] Figure 7 Another exemplary embodiment of the control flow graph is presented.

[0013] Figure 8 Another exemplary embodiment of the control dependency graph is presented. Detailed Implementation

[0014] Conventional processors are typically control-flow processors. However, computer engineers are currently developing processors that enable programs to execute without control-flow instructions. Specifically, engineers are developing processors that do not use a program counter to control the execution flow of a program. More specifically, the processor controls the execution flow not based on a program counter, but on the availability of data referenced by the program's instructions. This type of design can be called a "dataflow architecture." Similarly, a processor with a dataflow architecture can be called a "dataflow processor." Moreover, for the purposes of this disclosure, a dataflow language is a computer language that has instructions for manipulating data but no control-flow instructions. Similarly, dataflow instructions are computer instructions derived from a dataflow language, and a dataflow program is a computer program embodied or encoded in a dataflow language. Therefore, a dataflow processor is capable of executing dataflow programs, and dataflow programs do not use control-flow instructions.

[0015] In order for computer programs to execute directly on the processor, the architecture of the processor may require the program to be expressed in machine language or machine code. The machine language version or expression of a program can be considered the lowest-level expression. However, software developers typically write or create programs in higher-level languages ​​(such as assembly, C, etc.). The highest-level expression of a program can be called the program's "source code." Software developers can then use tools such as compilers, assemblers, and linkers to translate the program's source code into a lower-level expression of the program. Such tools are often called "translators."

[0016] Additionally, software developers can use translators to translate code from one language to another, where neither language needs to be inferior to the other. Nevertheless, the input code can still be called "source code" or "source program," and the resulting code can be called "object code."

[0017] Alternatively, a tool called an "interpreter" can be used to execute the high-level expression of a program on a processor. For example, the machine language expression of an interpreter can be executed directly on the processor, and the high-level expression of a program can be executed on the interpreter.

[0018] To create a computer program that performs a specific task or set of tasks, it may be easier for a software developer to write the program as a control-flow program than as a data-flow program. Furthermore, many different types of control-flow programs already exist, and it may be desirable to convert many of those programs into data-flow programs so that the converted programs can run on a data-flow processor. As described above, this disclosure relates to techniques for automatically converting control-flow programs into data-flow programs. Specifically, as described in more detail below, this disclosure relates to methods and apparatus for converting control-flow programs into data-flow programs using control dependency graphs.

[0019] Specifically, a tool called a dataflow converter can be used to convert a control flow program into a dataflow program. And, as part of the conversion process, as described in more detail below, the dataflow converter can assign different parts of the control flow program to different control dependency regions. The dataflow converter can then consider each definition and each use of each variable in the control flow program. If the definition is in a different control dependency region than the use, the dataflow converter can determine that a special dataflow instruction is required. This instruction can be referred to as a “switch” instruction, as shown below. As described in more detail below, the switch instruction can route values ​​to a specific channel based on the branch conditions of the defined region. Furthermore, the approach described herein allows the dataflow converter to avoid inserting unnecessary dataflow instructions, thereby keeping the dataflow graph small.

[0020] This disclosure presents an exemplary embodiment in which the data stream converter is implemented as part of a compiler. However, as described in more detail below, in other embodiments, the data stream converter may be implemented as part of a different type of tool or as a standalone tool.

[0021] Figure 1 This is a block diagram of an exemplary embodiment of a data processing system 100 having components including a data stream processor (DFP) 20 and a data stream converter 32. The DFP 20 is a processor that controls the execution flow based on the availability of data referenced by computer program instructions, rather than based on a program counter. In other words, the data stream processor 20 uses a data stream architecture. Figure 1 In this embodiment, the DFP 20 includes a number of different processing elements (PEs) 22. The PEs in the dataflow processor may also be referred to as "dataflow cores" (DFCs). Therefore, the DFCs 22 are capable of executing dataflow instructions. The DFP 20 also includes a number of different communication channels 24, which enable at least some of the DFCs to communicate with at least some other DFCs.

[0022] Furthermore, for the purposes of this disclosure, a communication channel is a data storage component within a DFP that can be written to and read from by multiple DFCs. For the purposes of this disclosure, unless the context explicitly states otherwise, "channel" should be understood to refer to a communication channel within a DFP. A channel can operate like a register in some respects. However, the primary purpose of a channel is generally to act as a buffer connecting inputs to its consumers. Typically, a data stream instruction either consumes or generates at least one channel.

[0023] As described above, the execution flow in DFP 20 is based on the availability of data in the instructions fed to the dataflow program. Therefore, each DFC 22 in DFP 20 is driven by its input.

[0024] In one embodiment, each DFC 22 is relatively simple, where a single core supports only 16 or fewer instructions. Furthermore, different DFCs in a DFP 20 can be capable of executing different dataflow instruction sets. Therefore, a DFP 20 can also be referred to as a "dataflow accelerator" (DFA). Thus, a DFA is an integrated circuit with many DFCs and many channels for interconnecting the DFCs.

[0025] Furthermore, the DFA can be dynamically configurable. For example, DFP 20 may include a DFA manager and various field-programmable gate arrays (FPGAs) or similar features, and the DFA manager can use those features to dynamically configure or reconfigure the number of DFCs 22, the type of DFCs 22, the number of channels 24, and other aspects of DFP 20. For example, the DFA manager can dynamically configure DFP 20 based on a dataflow graph. And to change the type of DFC, the DFA manager can configure one or more FPGAs (or similar features) in the DFC to change the DFC from an “ADD” core for one application to a “MULTIPLY” core for another application. In one embodiment or scenario, DFP 20 may include hundreds (e.g., 512) DFCs and hundreds (e.g., 512) channels. In other embodiments or scenarios, DFP 20 may have a larger or smaller number of DFCs and channels. And as described above, in one embodiment or scenario, the number of DFCs and channels can be dynamically changed for different applications.

[0026] exist Figure 1 In one embodiment, the DPS 100 also includes a conventional control flow processor (CFP) 10, an NVS 14, and RAM 12. The CFP 10 and DFP 20 may be capable of reading from and writing to the RAM 12 and NVS 14.

[0027] NVS 14 includes compiler 30, and compiler 30 includes data stream converter 32. Compiler 30 can be executed on CFP 10. For example, CFP 10 can copy compiler 30 from NVS 14 to RAM 12, and then CFP 10 can execute compiler 30 from RAM 12. Figure 1 In this embodiment, NVS 14 also includes a control flow program 40 to be converted into a data flow program 54. This control flow program is shown as source program 40. As described in more detail below, when compiler 30 executes, compiler 30 can use data stream converter 32 to convert source program 40 into data flow program 54. For example, as shown, compiler 30 can copy source program 40 from NVS 14 to RAM 12, and then compiler 30 can use data stream converter 32 to convert source program 40 into data flow program 54. The data flow program can then be executed on DFP 20. Alternatively or additionally, compiler 30 can copy data flow program 54 from RAM 12 to NVS 14 for future use.

[0028] The DPS 100 may also include various additional components, such as a network interface controller (NIC) 16 for communicating with other DPSs over the network.

[0029] Source program 40 includes various control flow instructions. Data flow program 54 does not include any control flow instructions. However, source program 40 and data flow program 54 are different representations or embodiments of code for performing the same task or multiple tasks. Therefore, from one perspective, source program 40 and data flow program 54 can be considered different embodiments or implementations of the same program. Additionally, as described in more detail below, data stream converter 32 can generate one or more intermediate representations (IRs) of the program. Such IRs can also be considered different embodiments or implementations of the same program.

[0030] As mentioned above, in Figure 1 In some embodiments, the data stream converter 32 is implemented as part of the compiler 30. In one embodiment or scenario, the compiler 30 is used to pre-compile the program, producing object code that can be executed later. In alternative embodiments or scenarios, the data stream converter may be part of a just-in-time (JIT) compiler or interpreter that converts the program's source code into object code while the program is running. Furthermore, in Figure 1In one embodiment, compiler 30 is typically located in NVS 14, and when compiler 30 is needed, DPS 100 loads compiler 30 into RAM 12 and executes compiler 30 from RAM 12. In another embodiment, DPS can run the compiler in the processor without loading the compiler into RAM. For example, the compiler can run from memory in the processor.

[0031] For the purposes of this disclosure, a translator is a computer program that reads in another program using one language (“input code”) and outputs a corresponding program using a different language (“output code”). For example, compilers and interpreters are types of translators. For the purposes of this disclosure, the input code of a translator may be referred to as “source code”, and the output code may be referred to as “object code”. Furthermore, for the purposes of this disclosure, a compiler is a type of translator that accepts a program using a high-level language (e.g., C) as input and outputs a corresponding program using a lower-level language (e.g., assembly code). Additionally, even... Figure 1 The data stream converter 32 is shown as part of a compiler, but in other embodiments, it may operate as a stand-alone converter, as part of another type of translator (e.g., a source-to-source translator), or as part of a completely different type of program (e.g., a piece of microcode in firmware that translates control flow code binary into data flow code). For the purposes of this disclosure, a data stream converter is a program that transforms a control flow program into a data flow program. Furthermore, this disclosure describes a data stream converter that performs such a transformation based on input including a control dependency graph.

[0032] Figure 2 This is a block diagram illustrating various diagrams and such diagrams used by the data stream converter 32 to convert the control flow program 40 into a data flow program 54. Specifically, Figure 2 The control flow graph 42, control dependency graph 44, list of control dependency regions 46, and data flow graph 50 are shown.

[0033] For illustrative purposes, this disclosure uses pseudocode to depict an exemplary list of instructions for source program 40. Specifically, source program 40 may include the following sequence of instructions:

[0034] 1:float function(float x,int n){

[0035] 2:for(unsigned i = 0; i <n;i++){

[0036] 3:if(i%2==0)

[0037] 4: x = x / 2;

[0038] 5:else

[0039] 6: x = x / 3;

[0040] 7:end-for;}

[0041] 8: return x;

[0042] In the pseudocode above, the % operator is the modulo operator. As part of the process of converting source program 40 into control flow program 54, data stream converter 32 can generate one or more IRs of source program 40. An IR (“IR#1”) can contain the following sequence of instructions:

[0043] 1:float function(float x,int n)

[0044] 2: if n < 0

[0045] 3: jump loop-end

[0046] 4:i=0

[0047] 5: loop-top

[0048] 6:if(i%2==0)

[0049] 7: x = x / 2

[0050] 8:else

[0051] 9:x = x / 3

[0052] 10: i = i + 1

[0053] 11:if i <n

[0054] 12: jump loop-top

[0055] 13: loop-end

[0056] 14: return x

[0057] The subsequent IR (“IR#2”) can group the instructions from IR#1 into basic blocks (BBs) as follows:

[0058] BB#0:

[0059] 1:float function(float x,int n)

[0060] 2: if n < 0

[0061] 3: jump loop-end

[0062] BB#1:

[0063] 4:i=0

[0064] BB#3:

[0065] 5: loop-top

[0066] 6:if(i%2==0)

[0067] BB#4:

[0068] 7: x = x / 2

[0069] BB#5:

[0070] 8:else

[0071] 9:x = x / 3

[0072] BB#6:

[0073] 10: i = i + 1

[0074] 11:if i <n

[0075] 12: jump loop-top

[0076] BB#2:

[0077] 13: loop-end

[0078] 14: return x

[0079] In the above example, IR#2 can use syntax similar to that used by the compiler infrastructure for IR, which is referred to by the name or trademark "low-level virtual machine" or "LLVM".

[0080] The data stream converter 32 can then generate a control flow graph 42 based on IR#2. For the purposes of this disclosure, a control flow graph for a program is a representation of that program that identifies or shows all possible or potential control transfers between the program's instructions or B-blocks. For example, in Figure 2 In the diagram, control flow graph 42 shows the possible control flow for source program 40 as follows:

[0081] ● Control can flow from BB#0 to BB#1 or BB#2;

[0082] ●Control can flow from BB#1 to BB#3 only;

[0083] ● Control can flow from BB#3 to BB#4 or BB#5;

[0084] ●Control can flow from BB#4 directly to BB#6;

[0085] ●Control can flow from BB#5 directly to BB#6;

[0086] ● Control can flow from BB#6 to BB#3 or BB#2; and

[0087] ● Control is not passed from BB#2 to any other block.

[0088] However, for illustrative purposes, control flow graph 42 is presented in a simplified form. In practice, data flow transformer 32 may include additional elements in the control flow graph (and possibly in one or more IRs of the source program) for handling boundary cases and other situations. For example, data flow transformer 32 may insert a "root" BB, an "exit" BB, and edges from the root BB to the exit BB. Such a root BB may also be referred to as a pseudo-entry BB. The following is about Figure 7 A less simplified version of the control flow graph is described.

[0089] In addition, control flow graphs can be in text or visual form. Figure 2 The visual form of the control flow graph 42 is shown. Alternatively, the data flow converter 32 can use a text form for the control flow graph 42. Any suitable data structure or combination of data structures can be used to represent the control flow graph in text form. For example, the data flow converter 32 can use one or more records, arrays, pointers, or any other suitable data structure or combination of data structures to store the control flow graph 42 in the DPS 100.

[0090] The data stream converter 32 can then use the control flow graph 42 to generate a control dependency graph 44 of the source program 40 (in textual, visual, or both forms). For the purposes of this disclosure, a control dependency graph for a program is a representation of the program according to a specific definition of "control dependency," which identifies or describes some or all control flow dependencies between instructions or Bs in the program.

[0091] Specifically, according to this disclosure, the data stream converter 32 can use a very specific definition of control dependency to determine which blocks control depend on themselves or on other blocks. This definition can be expressed by the following rule:

[0092] 1. Given two points (A, B) in a program, if there exists more than one path from A to the end, where one path passes through B and the other does not, then B's control depends on A.

[0093] 2. A point is an instance or iteration of (a) an instruction or basic block or (b) an instruction or basic block in a loop.

[0094] In addition, according to this disclosure, the data stream converter 32 uses the following rules to generate the control dependency graph:

[0095] An edge from A to B exists in the control dependency graph if and only if B is control-dependent on A. Furthermore, for the purposes of this disclosure, if point B is control-dependent on point A, then point A can be called the "parent" of point B. And if point B is directly control-dependent on point A, then point A can be called the "direct parent" of point B. However, if the control dependency is not the closest (or "direct"), then point A can be called the "indirect parent" of point B.

[0096] Furthermore, since instructions or different instances of a BB within a loop can be considered distinct points, an instruction or BB can be its own parent. For example, in control dependency graph 44, BB#6 has the following direct parent nodes: BB#0 and BB#6.

[0097] Figure 3 A flowchart illustrating an exemplary procedure for generating a control dependency graph is presented. For ease of understanding, Figure 3 A simplified process is illustrated. As will be appreciated by those skilled in the art, the process can be significantly modified in practice to improve efficiency, etc. In one embodiment, to generate a control dependency graph, the data stream converter can use a process similar to that described in the article entitled “Compact Representation of Control Dependencies” by Ron Cytron et al. (hereinafter “Cytron”). However, Cytron provides something that can be referred to as a “weak region”. In contrast, according to this disclosure, the data stream converter 32 can use a process that provides a strong region.

[0098] Figure 3 The process can begin after the data stream converter 32 has generated IR#2 and control flow graph 42. In one embodiment, the data stream converter 32 uses IR#2 and control flow graph 42 to perform... Figure 3 The determination shown in the figure, such as by Figure 2 The dashed arrows in the diagram illustrate the path from source code 40 and control flow graph 42 to control dependency graph 44. Figure 3As shown in box 210, the data flow converter 32 can then begin generating the control dependency graph 44 by determining whether it has analyzed all BBs for the dependency. Specifically, the data flow converter 32 can determine whether all potential primary BBs in the control flow graph 42 have been analyzed. If all potential primary BBs have not been analyzed, the data flow converter 32 can then select the BB to be considered as the primary BB (or "point A"), as shown in box 212. As shown in box 220, the data flow converter 32 can then determine whether all potential secondary BBs have been analyzed in conjunction with the primary BB. If there are no potential secondary BBs to be analyzed (or no more potential secondary BBs to be analyzed), the process can return to box 210 and possibly to 212, where the data flow converter 32 may select a new BB to act as the primary BB.

[0099] However, if there is at least one potential secondary BB to be analyzed, the data stream converter 32 can select a potential secondary BB to be considered as a secondary BB (or "point B"), as shown in box 222. As mentioned above, a secondary BB can be (a) a BB other than the primary BB or (b) another instance of the primary BB in a loop.

[0100] As shown in box 230, the data stream converter 32 can then determine whether any path in the control flow graph 42 from the main BB to the program end includes the secondary BB. In response to an affirmative determination, the data stream converter 32 can then determine whether any path from the main BB to the program end does not include the secondary BB, as shown in box 240. In response to the affirmative determinations in boxes 230 and 240, the data stream converter 32 can mark the secondary BB as control dependent on the main BB, as shown in box 242. Figure 3 The process can then return to box 220, where the data stream converter 32 determines whether all potential auxiliary BBs have now been analyzed.

[0101] Alternatively, in response to a negative affirmation at boxes 230 or 240, the process can return to box 220. If there are any other potential secondary BBs to be analyzed, the data stream converter 32 can analyze those BBs as described above. And after all potential secondary BBs have been analyzed, the process can flow from box 220 to box 210, and the data stream converter 32 selects a new BB to be considered as the primary BB, if there are any such BBs to be considered, as described above. Once all BBs have been analyzed for dependencies, the data stream converter 32 can save the results as a control dependency graph 44, as shown at box 244, and the process can end.

[0102] For example, when BB#0 is considered the primary BB and BB#1 is considered the secondary BB, the data stream converter 32 can determine that there exists a path from BB#0 to the end via BB#1, and another path from BB#0 to the end without via BB#1. Therefore, the data stream converter 32 can mark BB#1 as control dependent on BB#0. Similarly, when an instance or iteration of BB#6 is considered the primary BB and another instance or iteration of BB#6 is considered the secondary BB, the data stream converter 32 can determine that there exists a path from the first iteration of BB#6 to the end via the second iteration of BB#6, and another path from the first iteration of BB#6 to the end without via the second iteration of BB#6. Therefore, the data stream converter 32 can mark BB#6 as control dependent on itself.

[0103] The data stream converter 32 can therefore generate a control dependency graph 44, which identifies all control dependencies between the BBs of the source program 40. For example, control dependency graph 44 indicates that BB#0 and BB#2 from IR#2 do not have a control dependency on any other BB. Control dependency graph 44 also identifies the following dependencies:

[0104] ●BB#1 control depends on BB#0.

[0105] ●BB#6 control depends on itself and BB#0.

[0106] ● BB#3 control depends on BB#0 and BB#6.

[0107] ● BB#4 control depends on BB#3.

[0108] ● BB#5 control depends on BB#3.

[0109] The data stream converter 32 can then identify all control dependency regions in the source program 40. Furthermore, the data stream converter 32 can define the concept of control dependency regions using the following rules:

[0110] A control-dependent region is a sequence of one or more basic blocks in a control flow program, wherein (a) each basic block in the sequence directly controls the same parent basic block, and (b) each basic block in the sequence has the same execution frequency.

[0111] Figure 4 A flowchart illustrating an exemplary embodiment of the process for identifying control dependency regions is presented. In one embodiment, the data stream converter 32 uses a control dependency graph 44 to perform... Figure 4 The determination shown in the figure, such as Figure 2 The dashed arrows in the diagram 46, which guide the viewer from the control dependency graph 44 to the control dependency region, are shown in the diagram. Figure 4The process can begin at block 320 with data stream converter 32 determining whether all potential primary BBs in control dependency diagram 44 have been considered. If any potential primary BBs still need to be considered, data stream converter 32 can select one of those BBs to be considered as a primary BB, as shown in box 322. As shown in box 330, data stream converter 32 can then determine whether all potential secondary BBs have been combined with the primary BB for consideration. If all potential secondary BBs have been considered, the process can return to box 320, and data stream converter 32 can proceed to box 322 to select a new primary BB, if any potential primary BBs still need to be considered.

[0112] However, referring again to box 330, if any potential secondary BBs are to be considered, the data stream converter 32 can select one of those BBs to be considered as a secondary BB, as shown at box 332. As shown at box 340, the data stream converter 32 can then determine whether the primary BB and the secondary BB have the same set of parent nodes in the control dependency graph 44. In response to a positive determination, the data stream converter 32 can then determine whether the primary BB and the secondary BB have the same execution frequency, as shown at box 350. For example, in one embodiment, the control dependency graph 44 includes data for identifying loop and branch conditions, and other aspects of the source program 40, which the data stream converter 32 uses to determine the execution frequency. For example, the control dependency graph 44 may include data for identifying features similar to those shown in the data flow graph 50. As shown at box 354, if the primary BB and the secondary BB have the same parent nodes and the same execution frequency, the data stream converter 32 can assign the same control dependency region to the primary BB and the secondary BB. However, as shown in box 352, if the primary BB and the secondary BB do not have the same parent node and the same execution frequency, the data stream converter 32 can assign the primary BB and the secondary BB to different control dependency regions.

[0113] The process can then return to box 320, and the data stream converter 32 assigns each remaining BB to a control-dependent region, as described above. After all BBs have been assigned to regions, the data stream converter 32 can save the resulting list 46 of control-dependent regions, as shown in box 356, and the process can then end.

[0114] In one embodiment or scenario, the data stream converter 32 can assign each block (BB) of the source program 40 to a separate control dependency region because no BB has both (a) the same parent BB and (b) the same execution frequency. However, in other embodiments or scenarios, two or more BBs may belong to the same control dependency region. For example, a control flow program may include two non-cyclic basic blocks A and C, and a cyclic intermediate basic block B, and basic blocks A and C may belong to the same control dependency region.

[0115] The data flow converter 32 can then use the control dependency graph 44, the list of control dependency regions 46, and other data sources to generate a data flow graph corresponding to the source program 40.

[0116] Figure 5 A flowchart illustrating an exemplary embodiment of the process for generating a data flow graph is presented. In one embodiment, the data flow converter 32 uses IR#2, a control dependency graph 44, and a list 46 of control dependency regions to generate the graph. Figure 5 The determination shown in the figure, such as Figure 2 The dashed arrows in the diagram guide the flow from source program 40, control dependency graph 44, and list of control dependency regions 46 to data flow graph 50. Figure 5 The process can begin at box 410 with the data stream converter 32 assigning regions to each use of each variable in the source program. For example, the data stream converter 32 can use IR#2 to identify each use of each variable and use the control dependency graph 44 to determine which region each use resides in. As shown in box 420, the data stream converter 32 can then determine whether all source instructions in IR#2 have been analyzed. If any source instructions have not been analyzed, the data stream converter 32 can select the source instructions to be analyzed, as shown in box 422. As shown in box 430, the data stream converter 32 can then determine whether all variables in the selected instructions have been analyzed. If any of those variables have not been analyzed, the data stream converter 32 can select the variables to be analyzed, as shown in box 432.

[0117] As shown in box 440, the data stream converter 32 can then determine whether the region where the variable is defined is the same as the region where the variable is being used. If those regions are different, the data stream converter 32 can insert a switch instruction into the data flow graph 50, as shown in box 442. (The switch instruction is described in more detail below.) However, if those regions are the same, the data stream converter 32 can return from block 440 to block 430, and as described above, the data stream converter 32 selects another variable (if any) from the selected instruction to be analyzed.

[0118] Once all variables from the selected instruction have been analyzed, the process can return from box 430 to box 420, and the data stream converter 32 selects another instruction to be analyzed (if any), as described above. Once all instructions and all variables from those instructions have been considered, the data stream converter 32 can save the results as a data flow graph 50, as shown in box 450, and the process can then end.

[0119] For the purposes of this disclosure, the switch instruction is an instruction in the instruction set of the DFP 20, which (a) names a control channel, an input channel, and two output channels; (b) consumes values ​​from the control channel and the input channel; (c) selects one of the output channels based on the control channel; and (d) generates a value from the input channel on the selected output channel. The switch instruction may also be simply referred to as a "switch". In one embodiment, the switch instruction may use the following syntax:

[0120] C1,C2 = Switches Ctrl,Ci

[0121] in,

[0122] Ci is the input channel.

[0123] Ctrl is the control channel, and

[0124] C1 and C2 are output channels.

[0125] Furthermore, the switching command can actually apply the following semantics:

[0126] If(CTRL)

[0127] C2=Ci

[0128] Else

[0129] C1=Ci

[0130] Furthermore, for the purposes of this disclosure, the selection instruction is an instruction in the instruction set of DFP 20, which (a) names a control channel, two input channels, and an output channel; (b) selects one of the input channels based on the control channel; (c) consumes values ​​from the control channel and the selected input channel; and (d) produces values ​​from the selected input channel on the output channel. The selection instruction may also be simply referred to as "selection".

[0131] Figure 6 An example embodiment of the data flow diagram 50 is presented. As described above, the data flow converter 32 can be used with... Figure 5The process shown is similar to the one used to generate the data flow graph 50 based on input data such as control flow graph 42. Specifically, data flow graph 50 shows a portion of the data flow graph involving variable x. Data flow graph 50 may also include additional information (not shown) involving all other variables in source program 40 or all variables in the intermediate representation of source program 40 (e.g., IR#2).

[0132] exist Figure 6 In the diagram, each switch instruction (e.g., "B0: Switch") is represented by a trapezoid with a wide base. Furthermore, Figure 6 The rhombus shape is used to represent Boolean operations. Figure 6 It also includes rectangles to represent operations such as allocation and arithmetic. Figure 6 It also includes pick instructions. Each pick instruction is represented by a trapezoid with a wide base. For ease of reference, each pick instruction is also provided with a different subscript (e.g., Pick1).

[0133] Figure 6 It also includes various Communication Channel Identifiers (CCIs) to identify channels generated or consumed by instructions. Figure 6 In the diagram, each CCI is illustrated using arrows that guide the flow from the instruction that generates the value for that CCI to the instruction that consumes the value for that CCI. For illustrative purposes, Figure 6 The diagram shows (a) the control channel CCI that enters from the side for picking and switching, (b) the input (or "consumed") CCI that enters from the top, and (c) the output (or "generated") CCI that exits from the bottom. Furthermore, for illustrative purposes, Figure 6 The input channel and the output channel of the switch are marked with "T" and "F" to indicate the channel selected based on Boolean control. However, other types of control channels may be used in other embodiments or scenarios. Moreover, in one embodiment, the communication channel is insensitive to delay. Such a communication channel may be referred to as a "delay-insensitive channel" (LIC).

[0134] Moreover, in Figure 6 In this configuration, each switch is labeled with an identifier for the BB, which contains one or more instructions that the data stream converter 32 has actually converted or translated into that switch. For example, "B0: Switch" identifies BB#0 from IR#2 as the BB corresponding to that switch.

[0135] After generating the data flow graph 50, the data flow converter 32 can then use the data flow graph 50 to generate the data flow procedure 54. The following pseudocode illustrates an exemplary data flow procedure 54 based on the data flow graph 50:

[0136]

[0137]

[0138]

[0139] Figure 7 Another exemplary embodiment of the control flow graph is presented to further illustrate how the data stream converter 32 operates. Figure 7 In the middle, the control flow graph 510 is compared to Figure 2 The control flow graph 42 in the diagram is less simplified. For example, control flow graph 510 includes 11 BBs, including BBs labeled "1" through "9", a pseudo-entry root BB labeled "0", and an exit BB labeled "10". Typically, BBs correspond to source code (not shown). However, each BB includes text to identify the type of one or more operations to be performed by that BB. Moreover, the text in the BB is pseudocode, where a single letter with a % prefix (e.g., "%x") indicates a virtual register, and the string "phi" indicates a pseudofunction. Furthermore, although assignments can generally take the form "%a = %b op %c" (where "op" can be any kind of binary operator, such as ADD, MUL, DIV), the destination can be omitted in the pseudocode (e.g., "%a") when one or more operands used by the assignment are related to the discussion but not to the destination. Similarly, the destination of a function can be omitted when one or more variables used by a function are related to the discussion but not to the destination.

[0140] Specifically, control flow diagram 510 shows the following control flow:

[0141] ● Control can be passed from 0 to 1 or 10.

[0142] ● Control can be passed from 1 to 9 or 4.

[0143] ● Control is transferred from 9 to 2

[0144] ● Control is transferred from 2 to 3

[0145] ● Control can be transferred from 3 to 5 or 6.

[0146] ● Control is transferred from 5 to 7

[0147] ● Control is transferred from 6 to 7

[0148] ● Control can be transferred from 7 to 8 or 2.

[0149] ● Control is transferred from 8 to 4

[0150] ● Control is transferred from 4 to 10

[0151] Furthermore, control flow diagram 510 shows that %x is defined in 2 and used in 7 and 4.

[0152] Figure 8 Another exemplary embodiment of the control dependency graph is presented to further illustrate how the data stream converter 32 operates. Specifically, Figure 8 A control dependency graph 610 generated by the data stream converter 32 based on the control flow graph 510 is shown. Figure 8 Examples show that blocks 1 and 4 do not depend on any other blocks, block 7 depends on itself and block 1, and so on.

[0153] In one embodiment or scenario, the dataflow converter 32 can assign each BB in the control dependency graph 610 to a separate control dependency region. For example, if the dataflow converter 32 determines that the loop from 7 to 2 in the control flow graph 510 may be an infinite loop, then the dataflow converter 32 can determine that BBs 1 and 4 do not have the same execution frequency, and the dataflow converter 32 can therefore assign BBs 1 and 4 to different control dependency regions. Thus, the dataflow converter 32 can determine that no BB has both (a) the same parent BB and (b) the same execution frequency.

[0154] In another embodiment or scenario, the data stream converter 32 may assign each BB (except BB 1 and 4) in the control dependency graph 610 to a separate control dependency region, and the data stream converter 32 may assign BB 1 and 4 to the same control dependency region. For example, if the data stream converter 32 can determine that the loop from 7 to 2 in the control flow graph 510 is not an infinite loop, then the data stream converter 32 may assign BB 1 and 4 to the same control dependency region because those BBs have (a) the same parent BB and (b) the same execution frequency.

[0155] The following text describes how the dataflow converter 32 can use the control dependency graph 610 to generate a dataflow graph and a corresponding dataflow procedure. For example, the dataflow converter 32 can determine that (a) %z is used in 7 and defined in 2, and (b) 7 does not have a control dependency on 2. Therefore, the dataflow converter 32 can determine that no switch is needed for %z used in 7.

[0156] Furthermore, the data stream converter 32 can determine that (a) %w is used in 7 and defined in 1, and (b) 7's control depends on 1. (Or more generally, the data stream converter 32 can determine whether 1 dominates any block that 7's control depends on). Therefore, the data stream converter 32 can determine that a switch is needed for %w used in 7. The data stream converter 32 can then perform a bottom-up walk on the control dependency graph 610 to find the nearest block that 7's control depends on, to insert the switch at that block. The data stream converter 32 can then insert the switch at that block. Figure 8In this embodiment, 7 directly controls 1. Therefore, the data stream converter 32 can insert a switch for %w at 1.

[0157] Using the same approach, for %w used in 6, the data stream converter 32 can insert a switch for %w at 3.

[0158] Furthermore, the data stream converter 32 can determine that (a) %z is used in 8 and defined in 2, and (b) 2 is lower than 8 in the control dependency graph 610. Specifically, 2 is one level lower than 8. Generally, definition is at the same or higher level than use, unless a back edge exists (which can be asserted if necessary). To process %z in 8, the data stream converter 32 can trace 2 to the same level as 8 in the control dependency graph 610. In this trace, 7 (which is the cyclic latch block and self-loop) is at the same level as 8. Therefore, the data stream converter 32 can insert a switch for %z at 7.

[0159] Furthermore, the data stream converter 32 can determine that (a) %x is used in 2 and defined in 7, and (b) the control of 2 depends on 7. Therefore, the data stream converter 32 can insert a switch for %x at 7.

[0160] Furthermore, the data stream converter 32 can determine that (a) %x is used in 4 and defined in 7. This is another case where use is at a higher level than definition. Similar to the use of %z in 8, the data stream converter 32 moves up the hierarchy in the control dependency graph 610, finds the self-loop at 7, and inserts the switch for %x there.

[0161] As described, the dataflow converter uses a specific definition of control dependencies to generate a control dependency graph, and then uses the control dependency graph to generate a dataflow graph and a dataflow procedure. By using the approach described herein, the dataflow converter can generate a smaller dataflow graph than that created by other types of tools. This relatively small dataflow graph enables the dataflow converter to generate a relatively small dataflow procedure. Therefore, the dataflow procedure can be executed with less overhead compared to dataflow procedures from other types of tools. For example, the dataflow procedure can be smaller and consume less power.

[0162] In contrast, other types of tools may require modifications to the control flow graph. However, such modifications are error-prone, and may even be impossible (e.g., when the program might throw an exception). Such modifications may also require additional computation compared to a dataflow program generated according to this disclosure. For example, the control flow graph might need to be modified to translate an "if statement" into code that computes two branches. However, computed branches are typically energy-intensive.

[0163] The stream converter according to this disclosure avoids code duplication. When tools use code duplication, the resulting stream program can be larger. And when that program is mapped to a stream processor, it can occupy more silicon space, consume more power, and take longer to run (compared to at least some of the control flow programs that avoid code duplication). Additionally, this stream converter can complete the conversion process much faster than other types of tools.

[0164] Based on the principles and exemplary embodiments described and illustrated herein, it will be appreciated that the illustrated embodiments may be modified in arrangement and detail without departing from such principles. Furthermore, although expressions such as “embodiment,” “one embodiment,” “another embodiment,” etc., are used herein, these phrases are intended to broadly refer to the possibility of embodiments and are not intended to limit the invention to a particular embodiment configuration. As used herein, these phrases may refer to the same embodiments or different embodiments, and those embodiments may be combined to form other embodiments.

[0165] Furthermore, this disclosure can refer to instructions, functions, procedures, data structures, applications, microcode, configuration settings, and other types of data. As mentioned above, when data is accessed by a machine or device, the machine or device can respond by performing tasks, defining abstract data types or low-level hardware contexts, and / or performing other operations. For example, data storage devices, RAM, and / or flash memory can include various instruction sets that perform various operations when executed. Such instruction sets are generally referred to as software. And as mentioned above, software used during the boot process can be referred to as firmware. Software stored in non-volatile memory can also be referred to as firmware. Additionally, terms such as "program" and "module" are generally used to cover a wide range of software constructions, including applications, routines, drivers, subroutines, processes, and other types of software components. The software components described herein can be implemented using any suitable operating environment and programming language (or a combination of operating environment and programming language).

[0166] Alternative embodiments include machine-accessible media-encoded instructions or control logic for performing the operations described herein. Such embodiments may also be referred to as a program product. Such machine-accessible media may include, but are not limited to, tangible storage media such as magnetic disks, optical disks, RAM, read-only memory (ROM), and processors, controllers, and other components including RAM, ROM, and / or other storage facilities. For the purposes of this disclosure, the term "ROM" is generally used to refer to non-volatile memory devices such as erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash ROM, flash memory, etc.

[0167] It should also be understood that the hardware and software components described herein represent reasonably self-contained functional elements such that each functional element can be designed, constructed, or updated substantially independently of other functional elements. In alternative embodiments, many of the components may be implemented as hardware, software, or a combination of hardware and software to provide the functionality described and illustrated herein. In some embodiments, some or all of the control logic used to implement the described operations may be implemented in hardware logic (e.g., as part of an integrated circuit chip, a programmable gate array (PGA), an application-specific integrated circuit (ASIC), etc.).

[0168] Furthermore, it should be understood that any particular software module may include more than one component. For example, the master boot code module may include two or more components, and those components can cooperate to complete the operations of the master boot code module, such as booting to the OS.

[0169] Similarly, instructions for multiple components can be stored in a single non-transitory machine-accessible medium. In at least one other embodiment, two or more non-transitory machine-accessible media can be used to store instructions for related components. For example, instructions for one component can be stored in one medium, and instructions for another component can be stored in another medium. Alternatively, a portion of the instructions for one component can be stored in one medium, and the remaining instructions for that component (as well as instructions for other components) can be stored in one or more other media. Instructions can also be used in a distributed environment and can be stored locally and / or remotely for access by single-processor or multi-processor machines.

[0170] Similarly, the applications and / or other data described above as residing on a particular device in one exemplary embodiment may reside on one or more other devices in other embodiments. Furthermore, the computational operations described above as being performed on a particular device in one exemplary embodiment may be performed by one or more other devices in other embodiments.

[0171] This teaching can be applied to benefit many different kinds of data processing systems. Exemplary data processing systems may include, but are not limited to: accelerators, system-on-a-chip (SoC), wearable devices, handheld devices, smartphones, telephones, entertainment devices (e.g., audio devices, video devices, audio / video devices (e.g., televisions and set-top boxes)), vehicle processing systems, personal digital assistants (PDAs), tablets, laptops, portable computers, personal computers (PCs), workstations, servers, client-server systems, distributed computing systems, supercomputers, high-performance computing systems, computing clusters, mainframes, minicomputers, and other devices for processing or transmitting information. Therefore, unless otherwise expressly specified or required by context, references to any particular type of data processing system (e.g., a PC) should be understood to also cover other types of data processing systems. Furthermore, unless otherwise expressly specified, components described as coupled to each other, communicating with each other, responding to each other, etc., do not need to communicate continuously with each other and do not need to be directly coupled to each other. Similarly, when a component is described as receiving data from or sending data to another component, unless otherwise expressly specified, that data may be sent or received through one or more intermediate components. Additionally, some components of the data processing system can be implemented as adapter cards with interfaces (e.g., connectors) for communicating with the bus. Alternatively, devices or components can be implemented as embedded controllers using components such as programmable or non-programmable logic devices or arrays, ASICs, embedded computers, smart cards, etc. For the purposes of this disclosure, the term "bus" includes paths that can be shared by more than two devices as well as point-to-point paths. Moreover, for the purposes of this disclosure, a processor may also be referred to as a processing unit, processing element, CPU, etc.

[0172] Furthermore, while one or more exemplary processes have been described with respect to specific operations performed in a particular order, many modifications can be applied to those processes to derive many alternative embodiments of the invention. For example, alternative embodiments may include processes using fewer operations than all of the disclosed operations, processes using additional operations, and processes in which the various operations disclosed herein are combined, subdivided, rearranged, or otherwise modified.

[0173] Given the wide variety of useful substitutions that can be readily derived from the exemplary embodiments described herein, this detailed description is intended to be illustrative only and should not be considered as limiting the scope of coverage.

[0174] The following examples relate to further embodiments.

[0175] Example A1 is a data processing system that utilizes techniques for automatically converting control flow programs into data flow programs. The data processing system includes a processor, a non-transitory machine-readable medium responsive to the processor, and a translator stored in the machine-readable medium. When executed by the data processing system, the translator enables the system to (a) automatically generate a control dependency graph of the control flow program; (b) automatically generate a data flow graph based at least in part on the control dependency graph; and (c) automatically generate a data flow program based at least in part on the data flow graph.

[0176] Example A2 is a data processing system based on Example A1, wherein the translator, when executed, enables the data processing system to (a) automatically associate variables in the control flow procedure with different control dependency regions; (b) automatically determine, for at least one specific variable in the control flow procedure, whether the variable is defined in one control dependency region and used in different control dependency regions; and (c) automatically insert switch instructions into the data flow procedure in response to determining that the variable is defined in one control dependency region and used in different control dependency regions.

[0177] Example A3 is a data processing system according to Example A2, wherein a switch instruction names (i) a control channel for receiving control values, (ii) an input channel for receiving input values, and (iii) at least two output channels. Furthermore, the switch instruction is designed to perform the following actions when executed: (a) select one of the output channels based at least in part on the control values; and (b) generate an input value on the selected output channel.

[0178] Example A4 is a data processing system based on Example A3, wherein the switch instruction is also designed to consume control values ​​and input values ​​when executed.

[0179] Example A5 is a data processing system according to Example A1, wherein the translator, when executed, enables the data processing system to: (a) automatically identify control dependencies between basic blocks, wherein each control dependency relates to a control-dependent basic block and a parent basic block; (b) automatically determine the execution frequency of the basic blocks; and (c) automatically generate a list of control-dependent regions based at least in part on determinations of: (i) whether each basic block in the sequence of basic blocks directly controls the same parent basic block and (ii) whether each basic block in the sequence has the same execution frequency. Example A5 may also include features of any one or more of Examples A2 through A4.

[0180] Example A6 is a data processing system based on Example A1, wherein the control flow procedure has at least two points (A, B) and an end. Furthermore, the operation of automatically generating a control dependency graph includes: (i) determining whether there exists more than one path from point A to the end; (ii) if there exists more than one path from point A to the end, determining whether one of the paths passes through point B and the other path does not pass through point B; (iii) in response to determining (a) there exists more than one path from point A to the end and (b) one of the paths passes through B and the other path does not pass through point B, marking point B as control dependent on point A; and (iv) including an edge from point A to point B in the control dependency graph if and only if point B is control dependent on point A. Example A6 may also include features of any one or more of Examples A2 to A5.

[0181] Example A7 is a data processing system according to Example A6, wherein each of point A and point B includes at least one of the following: (a) instructions from a control flow procedure; (b) instances of instructions from a control flow procedure within a loop; (c) basic blocks from a control flow procedure; and (d) instances of basic blocks from a control flow procedure within a loop.

[0182] Example A8 is a data processing system based on Example A1, wherein the translator includes a compiler. Example A8 may also include features of any one or more of Examples A2 through A7.

[0183] Example A9 is a data processing system according to Example A1, wherein the processor includes a control flow processor, the data processing system also includes a data flow processor, and the translator includes control flow instructions to be executed by the control flow processor. Furthermore, when executed by the control flow processor, the translator enables the data processing system to store a data flow program on a machine-readable medium. Moreover, the control flow program includes a control flow version of the source program, and the data flow program includes a data flow version of the source program. The data flow program enables the data processing system to execute the data flow version of the source program on the data flow processor. Example A9 may also include features of any one or more of Examples A2 through A8.

[0184] Example B1 is an apparatus for automatically converting a control flow program into a data flow program. The apparatus includes a non-transitory machine-readable medium and a translator stored in the machine-readable medium. When executed by a data processing system, the translator enables the data processing system to (a) automatically generate a control dependency graph of the control flow program; (b) automatically generate a data flow graph based at least in part on the control dependency graph; and (c) automatically generate a data flow program based at least in part on the data flow graph.

[0185] Example B2 is an apparatus according to Example B1, wherein the translator, when executed, enables the data processing system to (a) automatically associate variables in the control flow procedure with different control dependency regions; (b) automatically determine, for at least one specific variable in the control flow procedure, whether the variable is defined in one control dependency region and used in different control dependency regions; and (c) automatically insert a switch instruction into the data flow procedure in response to determining that the variable is defined in one control dependency region and used in different control dependency regions.

[0186] Example B3 is an apparatus according to Example B2, wherein the switching instruction names (i) a control channel for receiving control values, (ii) an input channel for receiving input values, and (iii) at least two output channels. Furthermore, the switching instruction is designed to perform the following operations when executed: (a) select one of the output channels at least in part based on the control values; and (b) generate an input value on the selected output channel.

[0187] Example B4 is an apparatus according to Example B3, wherein the switch instruction is also designed to consume control values ​​and input values ​​when executed.

[0188] Example B5 is an apparatus according to Example B1, wherein the translator, when executed, enables the data processing system to: (a) automatically identify control dependencies between basic blocks, wherein each control dependency relates to a control-dependent basic block and a parent basic block; (b) automatically determine the execution frequency of the basic blocks; and (c) automatically generate a list of control-dependent regions based at least in part on determinations of (i) whether each basic block in the sequence of basic blocks directly controls the same parent basic block and (ii) whether each basic block in the sequence has the same execution frequency. Example B5 may also include features of any one or more of Examples B2 to B4.

[0189] Example B6 is an apparatus according to Example B1, wherein the control flow procedure has at least two points (A, B) and an end. Furthermore, the operation of automatically generating the control dependency graph includes: (i) determining whether there exists more than one path from point A to the end; (ii) if there exists more than one path from point A to the end, determining whether one of the paths passes through point B and the other path does not pass through point B; (iii) in response to determining that (a) there exists more than one path from point A to the end and (b) one of the paths passes through B and the other path does not pass through point B, marking point B as control dependent on point A; and (iv) including an edge from point A to point B in the control dependency graph if and only if point B is control dependent on point A. Example B6 may also include features of any one or more of Examples B2 to B5.

[0190] Example B7 is an apparatus according to Example B6, wherein each of points A and B includes at least one of the following: (a) instructions from a control flow procedure; (b) instances of instructions from a control flow procedure in a loop; (c) basic blocks from a control flow procedure; and (d) instances of basic blocks from a control flow procedure in a loop.

[0191] Example B8 is an apparatus according to Example B1, wherein the translator includes a compiler. Example B8 may also include features of any one or more of Examples B2 through B7.

[0192] Example B9 is an apparatus according to Example B1, wherein the translator includes control flow instructions to be executed by a control flow processor in a data processing system. Furthermore, when executed by the control flow processor, the translator enables the data processing system to store a data flow program on a machine-readable medium. Moreover, the control flow program includes a control flow version of the source program, and the data flow program includes a data flow version of the source program. The data flow program enables a device having a data flow processor to execute the data flow version of the source program on the data flow processor. Example B9 may also include features of any one or more of Examples B2 to B8.

[0193] Example C1 is a method for automatically converting a control flow procedure into a data flow procedure. The method includes: (a) automatically generating a control dependency graph of the control flow procedure using a translator executed in a data processing system; (b) automatically generating a data flow graph using a translator executed in a data processing system, based at least in part on the control dependency graph; and (c) automatically generating a data flow procedure using a translator executed in a data processing system, based at least in part on the data flow graph.

[0194] Example C2 is based on the method of Example C1, and further includes using a translator executed in a data processing system to automatically perform operations, the operations including: (a) associating variables in a control flow procedure with different control dependency regions; (b) for at least one specific variable in the control flow procedure, determining whether the variable is defined in one control dependency region and used in different control dependency regions; and (c) in response to determining that the variable is defined in one control dependency region and used in different control dependency regions, inserting a switch instruction into the data flow procedure.

[0195] Example C3 is based on the method of Example C2, wherein the switch instruction names (i) a control channel for receiving control values, (ii) an input channel for receiving input values, and (iii) at least two output channels. Furthermore, the switch instruction is designed to perform the following operations when executed: (a) select one of the output channels based at least in part on the control values; and (b) generate an input value on the selected output channel.

[0196] Example C4 is based on the method of Example C3, wherein the switch instruction is also designed to consume control values ​​and input values ​​when executed.

[0197] Example C5 is based on the method of Example C1, and further includes automatically performing operations using a translator executed in a data processing system, the operations including: (a) identifying control dependencies between basic blocks, wherein each control dependency relates to a control-dependent basic block and a parent basic block; (b) determining the execution frequency of the basic blocks; and (c) generating a list of control-dependent regions based at least in part on determinations of (i) whether each basic block in the sequence of basic blocks directly controls the same parent basic block and (ii) whether each basic block in the sequence has the same execution frequency. Example C5 may also include features of any one or more of Examples C2 through C4.

[0198] Example C6 is based on the method of Example C1, wherein the control flow procedure has at least two points (A, B) and an end. Furthermore, the operation of automatically generating the control dependency graph includes: (i) determining whether there exists more than one path from point A to the end; (ii) if there exists more than one path from point A to the end, determining whether one of the paths passes through point B and the other path does not pass through point B; (iii) in response to determining (a) there exists more than one path from point A to the end and (b) one of the paths passes through B and the other path does not pass through point B, marking point B as control dependent on point A; and (iv) including an edge from point A to point B in the control dependency graph if and only if point B is control dependent on point A. Example C6 may also include features of any one or more of Examples C2 through C5.

[0199] Example C7 is based on the method of Example C6, wherein each of points A and B includes at least one of the following from the group consisting of: (a) instructions from the control flow procedure; (b) instances of instructions from the control flow procedure in a loop; (c) basic blocks from the control flow procedure; and (d) instances of basic blocks from the control flow procedure in a loop.

[0200] Example C8 is based on the method of Example C1, where the translator includes a compiler. Example C8 may also include features of any one or more of Examples C2 through C7.

[0201] Example C9 is a method according to Example C1, wherein the translator includes control flow instructions to be executed by a control flow processor in the data processing system. Furthermore, the control flow program includes a control flow version of the source program, and the data flow program includes a data flow version of the source program. The method also includes executing the data flow version of the source program on the data flow processor. Example C9 may also include features of any one or more of Examples C2 through C8.

[0202] Example D is at least one machine-accessible medium that includes computer instructions for automatically converting a control-flow procedure into a data-flow procedure. The computer instructions, in response to being executed in the device, enable the device to perform a method according to any one of Examples C1 through C9.

[0203] Example E is a data processing system that utilizes techniques for automatically converting control-flow procedures into data-flow procedures. The data processing system includes processing elements, at least one machine-accessible medium responsive to the processing elements, and computer instructions at least partially stored in the at least one machine-accessible medium. The computer instructions, in response to being executed, enable the data processing system to perform a method according to any one of Examples C1 to C9.

[0204] Example F is a data processing system that utilizes techniques for automatically converting control-flow procedures into data-flow procedures. The data processing system includes units for executing the methods of any of Examples C1 through C9.

Claims

1. A data processing system utilizing techniques for automatically converting control flow procedures into data flow procedures, the data processing system comprising: processor; A non-transitory machine-readable medium that responds to the processor; as well as A translator, stored in the machine-readable medium, wherein, when executed by the data processing system, the translator enables the data processing system to: Automatically generate the control dependency graph of the control flow program; A data flow graph is automatically generated, at least in part, based on the control dependency graph. For at least one variable in the control flow procedure, automatically determine whether the at least one variable is defined in one control dependency region and used in different control dependency regions; and Based at least in part on the data flow graph, a data flow procedure is automatically generated, including automatically inserting a switch instruction into the data flow procedure in response to determining that the at least one variable is defined in one control dependency region and used in different control dependency regions, wherein the switch instruction, when executed by the data flow processor, causes an input value to be generated on a selected output channel of at least two output channels.

2. The data processing system according to claim 1, wherein: The switch instruction names (i) a control channel for receiving control values, (ii) an input channel for receiving said input values, and (iii) the at least two output channels; and The switch command is designed to perform the following actions when executed: One of the output channels is selected, at least in part, based on the control value.

3. The data processing system according to claim 2, wherein, The switch command is also designed to consume the control value and the input value when executed.

4. The data processing system according to claim 1, wherein, When the translator is executed, it enables the data processing system to: Automatically identify control dependencies between basic blocks, where each control dependency involves the controlling dependency basic block and the parent basic block; Automatically determine the execution frequency of basic blocks; and A list of control dependency regions is automatically generated, based at least in part on the determination of (a) whether each basic block in the basic block sequence directly controls the same parent basic block and (b) whether each basic block in the sequence has the same execution frequency.

5. The data processing system according to claim 1, wherein: The control flow procedure has at least two points (A, B) and an end; and The operations for automatically generating the control dependency graph include: Determine whether there is more than one path from point A to the end point; If there is more than one path from point A to the end, determine whether one of the paths passes through point B and the other path does not pass through point B. In response to determining that (a) there exists more than one path from point A to the end and (b) one of the paths passes through point B and another of the paths does not pass through point B, point B is marked as control dependent on point A; and An edge from point A to point B is included in the control dependency graph if and only if point B is control-dependent on point A.

6. The data processing system according to claim 5, wherein, Each of points A and B includes at least one item from a group consisting of: Instructions from the control flow program; Instances of instructions from the control flow procedure, within a loop; Basic blocks from the control flow program; and An instance from a loop in the basic block of the control flow program.

7. The data processing system according to claim 1, wherein, The translator includes a compiler.

8. The data processing system according to claim 1, wherein: The processor includes a control flow processor; The data processing system also includes a data stream processor; The translator includes control flow instructions to be executed by the control flow processor; When the translator is executed by the control flow processor, it enables the data processing system to store the data flow program in the machine-readable medium; The control flow procedure includes a control flow version of the source program; The data stream program includes a data stream version of the source program; and The data stream program enables the data processing system to execute a data stream version of the source program on the data stream processor.

9. A method for automatically converting a control flow procedure into a data flow procedure, the method comprising: Use a translator executed in the data processing system to automatically generate the control dependency graph of the control flow program; The translator, which is executed in the data processing system, automatically generates a data flow graph, at least in part, based on the control dependency graph. Using the translator executed in the data processing system, for at least one variable in the control flow program, it is automatically determined whether the at least one variable is defined in one control dependency region and used in different control dependency regions; as well as Using the translator executed in the data processing system, a data flow procedure is automatically generated based at least in part on the data flow graph, including automatically inserting a switch instruction into the data flow procedure in response to determining that the at least one variable is defined in one control dependency region and used in different control dependency regions, wherein the switch instruction, when executed by the data flow processor, causes an input value to be generated on a selected output channel of at least two output channels.

10. The method according to claim 9, wherein: The switch instruction names (i) a control channel for receiving control values, (ii) an input channel for receiving said input values, and (iii) the at least two output channels; and The switch command is designed to perform the following actions when executed: One of the output channels is selected, at least in part, based on the control value.

11. The method according to claim 10, wherein, The switch command is also designed to consume the control value and the input value when executed.

12. The method according to claim 9, further comprising: The translator, which is executed in the data processing system, is used to automatically perform operations, including: Identify control dependencies between basic blocks, where each control dependency involves the controlling dependency basic block and the parent basic block; Determine the execution frequency of the basic blocks; and A list of control-dependent regions is generated based at least in part on the determination of (a) whether each basic block in the basic block sequence directly controls the same parent basic block and (b) whether each basic block in the sequence has the same execution frequency.

13. The method according to claim 9, wherein: The control flow procedure has at least two points (A, B) and an end; and The operations for automatically generating the control dependency graph include: Determine whether there is more than one path from point A to the end point; If there is more than one path from point A to the end, determine whether one of the paths passes through point B and the other path does not pass through point B. In response to determining that (a) there exists more than one path from point A to the end and (b) one of the paths passes through point B and another of the paths does not pass through point B, point B is marked as control dependent on point A; and An edge from point A to point B is included in the control dependency graph if and only if point B is control-dependent on point A.

14. The method according to claim 13, wherein, Each of points A and B includes at least one item from a group consisting of: Instructions from the control flow program; Instances of instructions from the control flow procedure, within a loop; Basic blocks from the control flow program; and An instance from a loop in the basic block of the control flow program.

15. The method according to claim 9, wherein, The translator includes a compiler.

16. The method according to claim 9, wherein: The translator includes control flow instructions to be executed by the control flow processor in the data processing system; The control flow procedure includes a control flow version of the source program; The data stream program includes a data stream version of the source program; and The method also includes executing a data stream version of the source program on a data stream processor.

17. At least one machine-accessible medium comprising computer instructions for automatically converting a control-flow program into a data-flow program, wherein, The computer instructions are executed in response to enable the device to perform the method according to any one of claims 9-16.

18. A data processing system utilizing techniques for automatically converting control flow procedures into data flow procedures, the data processing system comprising: Process elements; At least one machine-accessible medium in response to the processing element; as well as Computer instructions stored at least partially in the at least one machine-accessible medium, wherein the computer instructions, in response to being executed, enable the data processing system to perform the method according to any one of claims 9-16.

19. A data processing system utilizing techniques for automatically converting control flow procedures into data flow procedures, the data processing system comprising: A unit for performing the method according to any one of claims 9-16.

20. A computer program product comprising instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 9-16.

Images