Program compiling method, electronic equipment and program product

Abstract

The invention provides a program compiling method. The program compiling method comprises the steps that a P4 program is converted into a first control flow diagram; edges in the first control flow graph comprise control edges for representing control relations, and node attributes in the first control flow graph comprise definition variables and use variables; according to a matching relationship between the definition variable and the use variable, constructing a data dependence edge in the first control flow diagram to obtain a second control flow diagram; and converting the second control flow graph into a program corresponding to the target compiling language according to a translation rule, a control edge and a data dependence edge between the elements of the P4 language and the corresponding elements of the target language. The disclosure also provides an electronic device and a computer program product.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, in particular, to a program compiling method, an electronic device and a program product. BACKGROUND

[0002] With the development of software-defined networking (SDN) and network functions virtualization (NFV) technologies, the programmability of network data plane has gradually become a key factor in building flexible and efficient network architecture. In this context, P4 (Programming Protocol-Independent Packet Processors) as a domain-specific programming language for data plane has received widespread attention in recent years. P4 allows developers to define the parsing, matching and forwarding behavior of network devices on data packets in a protocol-independent manner, thereby realizing customized programming of the data plane logic of devices such as switches and routers.

[0003] P4 language is developed by Open Networking Foundation (ONF) and its standardization and tool chain construction are promoted by the open source community. The language supports the declarative description of packet header format, parsing process, match-action table and control plane interface, and has been widely applied to programmable switch chips, FPGA accelerators and virtual switches and other platforms.

[0004] However, as P4 programs are increasingly widely deployed in critical network infrastructure, the correctness and reliability of the programs have become increasingly prominent. Since P4 programs directly control the processing flow of data packets, any logical error or security vulnerability may cause network interruption, traffic anomaly or even security risks. Therefore, how to effectively formalize the verification of P4 programs has become an important research direction to ensure the correctness of network data plane functions.

[0005] A variety of verification methods for P4 programs have been proposed in the prior art, among which converting P4 programs into other formal modeling languages (such as Promela) is an important means to promote the verification of P4 programs. However, this method still has several limitations.

[0006] Firstly, P4 language has unique semantic structure, including hierarchical packet parser, table-based state pipeline, control plane interaction mechanism, etc., which are difficult to be accurately expressed by traditional program analysis model (such as control flow graph). For example, the nonlinear jump behavior driven by table matching result in P4 cannot be completely described by the standard control flow model, resulting in insufficient modeling accuracy of existing analysis tools.

[0007] Secondly, due to the lack of a unified and complete compilation conversion framework from P4 to formal modeling language, most existing methods use simplified modeling strategies, ignoring some complex language features (such as register array, counter, external function call, concurrent parsing branch, etc.), to reduce model complexity. Such simplification helps to alleviate the state space explosion problem, but at the expense of semantic fidelity, which may lead to incomplete verification results or false positives / false negatives.

[0008] In addition, completely and accurately modeling all semantic behaviors of P4 programs will lead to a sharp expansion of the state space, making it difficult for existing model detection tools to complete the verification task within an acceptable time. Therefore, the current technology cannot balance between model integrity and verification feasibility, and has not yet provided a technical solution that can fully reflect the semantic features of P4 programs while effectively controlling the complexity of verification.

[0009] In summary, the existing technology still faces technical challenges such as incomplete modeling, incomplete function coverage, and low verification efficiency when formalizing and verifying P4 programs. Therefore, it is urgent to propose a new technical solution to solve the above-mentioned defects in the semantic modeling and formal verification process of P4 programs, and to improve the reliability and security of network data plane programs. SUMMARY

[0010] The present disclosure provides a program compilation method, an electronic device and a program product.

[0011] According to one aspect of the present disclosure, a program compilation method is provided, which can include: converting a P4 program into a first control flow graph; the edges in the first control flow graph include control edges for representing control relationships, and the node attributes in the first control flow graph include defined variables and used variables; the defined variables are variables defined in the statements corresponding to the nodes; the used variables are variables used in the statements corresponding to the nodes; constructing data dependency edges in the first control flow graph according to the matching relationship between the defined variables and the used variables, to obtain a second control flow graph; the data dependency edges point from the nodes where the defined variables are located to the nodes where the used variables matched with the defined variables are located; and converting the second control flow graph into a program corresponding to a target language according to translation rules between elements of the P4 language and corresponding elements of the target language, the control edges and the data dependency edges.

[0012] In some embodiments, converting the P4 program into the first control flow graph comprises: constructing an initial node as a program entry node in the first control flow graph; traversing a set of top-level definition objects of the P4 program to find instances of composite component types, and for each found instance, constructing a sub-control flow graph of the instance in the first control flow graph, and connecting the sub-control flow graph of each instance sequentially after the program entry node in the order of execution of the instances via sequential edges; the sequential edges are used to represent sequential relationships; and marking the last node in the sub-control flow graph of the last instance as a program exit node when the sub-control flow graph of the last instance is constructed.

[0013] In some embodiments, constructing the sub-control flow graph of the instance in the first control flow graph comprises: constructing a declaration node of the instance in the first control flow graph, and connecting the declaration node after the program entry node or the last node in the sub-control flow graph of the previous instance via a sequential edge; constructing a sub-control flow graph of each sub-component according to each sub-component referenced by the instance, and connecting the sub-control flow graph of each sub-component sequentially after the declaration node of the instance in the order of execution of the sub-components within the instance via sequential edges; and constructing an instance exit node of the instance after the last sub-component, and constructing a sequential edge from the last node in the sub-control flow graph of the last sub-component to the instance exit node.

[0014] In some embodiments, the method of constructing the sub-control flow graph of the sub-component comprises: initializing a node stack for recording starting points of the control edges used in the construction process; constructing a phase node of the sub-component in the first control flow graph, and connecting the phase node after the declaration node of the instance to which the sub-component belongs or the last node of the sub-control flow graph of the previous sub-component via a sequential edge, while pushing the phase node into the node stack; constructing a sub-control flow graph of each statement according to each statement contained in the sub-component, and connecting the sub-control flow graph of each statement sequentially after the phase node of the sub-component in the order of execution of the statements within the sub-component via sequential edges; and constructing a control edge from the corresponding node at the top of the node stack to the statement entry node of the sub-control flow graph of each statement; and popping the phase node of the sub-component from the node stack when the sub-control flow graph of the last statement contained in the sub-component is constructed.

[0015] In some embodiments, when the type of the statement is an assignment statement, the method of constructing the sub-control flow graph of the statement comprises: constructing an assignment node representing the assignment statement as a statement entry node, and saving the left value of the assignment statement into a definition variable field of the assignment node, and saving all variable names involved in the right value expression of the assignment statement into a used variable field of the assignment node.

[0016] In some embodiments, when the type of the statement is a conditional branch statement, the method for constructing the sub-control flow graph of the statement comprises: constructing a condition judgment node as a statement entry node of the conditional branch statement; traversing the judgment result of the conditional branch statement; constructing a branch entry node of the judgment result and pushing it into the node stack, while constructing a sequential edge from the condition judgment node to the branch entry node and setting a label representing the judgment result on the sequential edge; according to the execution statements of the judgment result, constructing the sub-control flow graph of each execution statement, and connecting the sub-control flow graphs of the execution statements in sequence after the branch entry node of the judgment result through sequential edges according to the execution order of the execution statements in the conditional branch statement; while constructing the sub-control flow graph of each execution statement, constructing control edges from the corresponding node at the top of the node stack to each node contained in the sub-control flow graph of each execution statement; when the sub-control flow graph of the last execution statement of the judgment result is constructed, popping the branch entry node from the node stack; when the traversal of the judgment result is completed, constructing a confluence node and connecting the confluence node to the last node in the sub-control flow graph of the last execution statement of each judgment result through a sequential edge.

[0017] In some embodiments, when the type of the statement is a table application statement, the method for constructing the sub-control flow graph of the statement comprises: constructing a table call node as a statement entry node of the table application statement, and pushing the table call node into a node stack; obtaining table information of the table application statement; the table information comprises a matching key list and an action list; constructing a matching node, and connecting the matching node after the table call node through a sequential edge, while constructing a control edge from a corresponding node at the top of the node stack to the matching node; setting a corresponding number of conditional branches according to the number of matching keys contained in the matching key list; traversing the conditional branches; constructing a rule condition node of the conditional branch and pushing it into the node stack, connecting the rule condition node after the matching node through a sequential edge, and setting a label on the sequential edge connecting the matching node and the rule condition node, the label indicating a matching item corresponding to the conditional branch to which the rule condition node belongs; finding an action call statement of the conditional branch according to the action list, constructing a sub-control flow graph of the action call statement according to the found action call statement, and connecting the sub-control flow graph of the action call statement after the rule condition node through a sequential edge, while constructing a control edge from a corresponding node at the top of the node stack to a node in the sub-control flow graph of the action call statement; when the sub-control flow graph of the action call statement is constructed, the rule condition node is popped from the node stack; when the traversal of the conditional branches is completed, a table exit node is constructed, and the table exit node is connected after the last node of the sub-control flow graph of each conditional branch and the matching node through a sequential edge; the table call node is popped from the node stack.

[0018] In some embodiments, when the type of the statement is an action call statement, the method for constructing the sub-control flow graph of the statement comprises: constructing an action call node as a statement entry node of the action call statement, and pushing the action call node into a node stack; constructing a sub-control flow graph of each action statement according to all action statements of the action called by the action call statement, and connecting the sub-control flow graphs of the action statements in series after the action call node through sequential edges according to the execution order of the action statements; when constructing the sub-control flow graph of each action statement, a control edge from a corresponding node at the top of the node stack to a node in the currently constructed sub-control flow graph is constructed according to the type of each action statement; when the sub-control flow graph of the last action statement is constructed, the action call node is popped from the node stack.

[0019] In some embodiments, when the type of the statement is an exit statement, the method for constructing the sub-control flow graph of the statement comprises: constructing an exit node representing the exit statement; the exit node is used to be connected to the instance exit node or the program exit node through a sequential edge.

[0020] In some embodiments, when the type of the statement is recommit, recirculation, mirror or clone, the method of constructing the sub-control flow graph of the statement comprises: constructing a call node of the recommit, recirculation, mirror or clone statement, and adding a call flag field in the node attribute of the call node, and setting the value of the call flag field to true; after the construction of the program exit node is completed, detecting whether the value of the call flag field corresponding to the call node is true, and if so, constructing a sequential edge from the program exit node to the program entry node.

[0021] In some embodiments, when the type of the statement is a block statement, the method of constructing the sub-control flow graph of the statement comprises: constructing a block entry node as the statement entry node of the block statement and pushing it into the node stack; constructing the sub-control flow graph of each statement according to each statement contained in the block statement, and sequentially connecting the sub-control flow graphs of each statement after the block entry node through sequential edges in the order of the execution of each statement in the block statement, while constructing a control edge from the corresponding node at the top of the node stack to the statement entry node in the sub-control flow graph of each statement; when the sub-control flow graph of the last statement contained in the block statement is constructed, popping the block entry node from the node stack; constructing a block exit node and connecting it after the last node of the sub-control flow graph of the last statement through a sequential edge.

[0022] In some embodiments, the data dependency edge is constructed in the first control flow graph according to the matching relationship between the definition variable and the use variable, comprising: traversing the nodes in the first control flow graph, extracting the definition variable set and the use variable set of each node; traversing the use variable set of each node, for each use variable in the use variable set of the current node, finding all the definition variables matched therewith from the definition variable set of other nodes, and taking the nodes where all the matched definition variables are found as the candidate definition nodes of the current node; for each candidate definition node, constructing a directed edge from the candidate definition node to the current node as a data dependency edge.

[0023] In some embodiments, after taking the nodes where all the matched definition variables are found as the candidate definition nodes of the current node, it further comprises: screening all the candidate definition nodes, and using the screened candidate definition nodes to construct the data dependency edge; the screening method comprises: selecting the candidate definition node with the latest construction time from all the candidate definition nodes; and selecting the candidate definition node in the same control flow branch or scope as the current node from all the candidate definition nodes.

[0024] In some embodiments, the matching in the finding of all the definition variables matched therewith from the definition variable set of other nodes comprises: the same variable name; and the variable name containing a prefix or suffix inclusion relationship.

[0025] According to another aspect of the present disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, so that the processor executes the program compilation method of any embodiment of the present disclosure.

[0026] According to still another aspect of the present disclosure, a readable storage medium is provided, in which execution instructions are stored, the execution instructions being executed by a processor to implement the program compilation method of any embodiment of the present disclosure.

[0027] According to still another aspect of the present disclosure, a computer program product is provided, comprising a computer program, the computer program being executed by a processor to implement the program compilation method of any embodiment of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0028] The accompanying drawings illustrate exemplary embodiments of the present disclosure and together with the description, explain the principles of the present disclosure, in which:

[0029] Figure 1 is a flowchart of a program compilation method of an exemplary embodiment of the present disclosure.

[0030] Figure 2 is a flowchart of a first control flow graph construction method of an exemplary embodiment of the present disclosure.

[0031] Figure 3 is a flowchart of a sub-control flow graph construction method of an exemplary embodiment of the present disclosure.

[0032] Figure 4 is a flowchart of a data dependence edge construction method of an exemplary embodiment of the present disclosure.

[0033] Figure 5 is a schematic structural block diagram of a P4 program compilation electronic device of an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0034] The present disclosure will be further described below in conjunction with the drawings and examples. It can be understood that the specific examples described herein are only used to explain the related content, and not to limit the present disclosure. In addition, it should be noted that only parts related to the present disclosure are shown in the drawings for ease of description.

[0035] It should be noted that the embodiments and features in the embodiments of the present disclosure can be combined with each other without conflict. The technical solutions of the present disclosure will be described in detail below with reference to the drawings and in conjunction with the embodiments.

[0036] Unless otherwise indicated, the exemplary embodiments / examples shown are to be understood as providing exemplary features of various details that can be implemented in practice to embody the technical concepts of the present disclosure. Thus, features of various embodiments / examples can be additionally combined, separated, interchanged, and / or rearranged, without departing from the technical concepts of the present disclosure, unless otherwise indicated.

[0037] The terminology used herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Furthermore, to the extent that the terms "including," "includes," "containing," "contains," or "containing," "contains," or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising" as an open transition term without precluding any additional or other elements. It is also noted that, as used herein, the terms "substantially," "approximately," and other similar terms are used as synonyms for "about," and are employed to account for inherent variations in measuring, calculating, and / or providing a value or quantity that is approximately the same as a specified reference amount, value, or quantity.

[0038] Figure 1 A flowchart schematic diagram of a program compiling method S100 of an embodiment of the present disclosure is shown. In the following, the program compiling method S100 will be described in detail according to the flowchart schematic diagram. Figure 1 The various steps of the program compiling method S100 will be described in detail.

[0039] In step S110, the P4 program is converted into a first control flow graph.

[0040] In the technical fields of program analysis, compilation optimization, static detection, and software verification, a control flow graph (CFG) as an important tool for abstract modeling of program execution logic is widely used in compiler internal representation, code optimization, vulnerability detection, program understanding, and test case generation scenarios. The control flow graph is used to represent all possible paths that a program may pass through during execution, reflecting the transfer relationship of the program control structure, and is one of the basic data structures for program static analysis and dynamic behavior simulation.

[0041] A first control flow graph is generally composed of nodes (also called control flow nodes) and edges. Exemplarily, a node is represented by a CFGNode structure, which contains a unique identifier id, a node name name, a node type type (a NodeType enumeration defines the types of nodes, including control block, parser, condition, basic statement, entry node, exit node, etc.), and a code string that the node represents. In addition, CFGNode maintains two variable fields: genVars records all the variables defined (called defined variables) by the statements corresponding to the node, and useVars records all the variables used (called used variables) by the statements corresponding to the node. A directed edge in the control flow graph is represented by a CFGEdge structure, which contains a source node ID, a target node ID, an edge type, and a label. The types of edges are generally divided into two categories: one is a sequential edge representing the order of program execution (for example, the connection between the internal or statement order execution of a basic block), and the other is a control edge representing a structured control relationship (for example, from the block entry node of a control block to its internal statement node, or from the condition judgment node to the entry node of each branch). The label of the edge is used to describe additional information on the control flow path, such as the judgment value of the conditional branch, the state transition name, etc.

[0042] Control edges are used to describe structured control relationships. In some embodiments, in order to ensure that the correct parent node can be associated when generating control edges, a node stack nodeStack mechanism is used to handle various nested control structures. The node stack is a stack used to store nodes, which is used to record the starting point used by the control edge during construction, facilitating the addition of subsequent control edges. After creating the node stack, whenever a new control component (such as a parser, control, etc. subcomponent, control block, action, or conditional branch, etc.) is entered, the current node is pushed onto the stack (the current node used for pushing onto the stack is different for different control components, such as a stage node for a subcomponent, a block entry node for a control block, an action call node for an action, and a branch entry node for a conditional branch). For example, when processing a P4 control, a “control <name>The node is pushed into the node stack; then, regardless of whether an assignment or an if statement occurs inside the control, the control node is connected to the new statement node by addControlEdge(nodeStack.top(), newNode,...). This control edge records the statement membership relationship, which is convenient for subsequent analysis. When the control is traversed, the nodes in the node stack are popped, and the global currentNode moves to the exit node of the control.

[0043] The conversion process of the first control flow graph is to convert the branch structure, table application, and special operations of the P4 program into a control flow graph representation while maintaining the semantics of the original P4 program.

[0044] In some embodiments, the conversion of the first control flow graph is performed according to the IR (Intermediate Representation) tree of the compiled P4 program. The IR tree can be obtained by P4 program compilation software (such as the P4c compiler). In the specific implementation of step S110, the execution order and branch structure of the P4 program can be identified through the IR tree, and converted into a graphical representation (i.e., the first control flow graph).

[0045] In step S120, data dependency edges are constructed in the first control flow graph according to the matching relationship between defined variables and used variables, to obtain a second control flow graph.

[0046] The second control flow graph is a control flow graph obtained by adding data dependency edges to the first control flow graph.

[0047] Currently, there is a lack of a dedicated framework for P4 programs to extract the control flow graph and data dependency relationship of the program. Many existing tools do not have independent "data flow extractor" and "control flow extractor" modules, which leads to insufficient consideration of the dependency relationship between variables and message fields in the P4 program. This deficiency either retains a large amount of logic and state unrelated to the properties to be verified (introducing redundant states leads to state space expansion), or lacks dependency analysis and adopts manual simplification, which may miss key influencing factors and weaken the accuracy of verification.

[0048] The data dependency edge corresponds to the def-use dependency, which is constructed by analyzing the variable read-write relationship of each statement. By adding data dependency edges, the first control flow graph can be extended to a program dependency graph containing data flow information (i.e., the second control flow graph). Exemplarily, the type of the data dependency edge is marked as "data", and the data dependency edge points from the defined variable node to the used variable node belonging to the same variable (i.e., the variable with a matching relationship).

[0049] In one embodiment, a special set (e.g., the dataEdges set) is constructed to store all data dependency edges. When generating the second control flow graph, the reaching definitions are computed and the data dependency edges are generated by calling special data dependency analysis functions (e.g., computeReachingDefinitions and generateDataEdgesFromRD). In the finally generated second control flow graph, each node is provided with dependency edges pointing to the definitions of the variables used by the node in addition to the sequential and / or branch control flow edges, thereby completely representing the control flow and data flow relationships of the program.

[0050] Step S130: converting the second control flow graph into a program corresponding to the target language according to the translation rules between the elements of the P4 language and the corresponding elements of the target language, the control edges and the data dependency edges.

[0051] The target language is a language after the P4 program is compiled. In some embodiments, the target language can be Promela, a formal model language. In addition to Promela, other formal model languages such as SMV, Alloy, TLA+, etc. can also be considered as the target language.

[0052] The translation rules are used to map the translation rules between the P4 elements and the corresponding elements of the target language. In this embodiment, Promela is taken as an example of the language to be compiled. The corresponding translation rules are shown in Table 1 and Table 2. Table 1 introduces the corresponding translation rules between the general elements in P4 and Promela, and Table 2 introduces the corresponding translation rules between the special elements (non-general elements) in P4 and Promela.

[0053] Table 1 Table 2 The present disclosure fills the technical gap in the prior art that there is no open source solution for automatically generating a P4 program into a formal verification model. On the basis of preserving the original semantics of P4, the verification model corresponding to other target languages is automatically constructed, the verification process is fully automated, and the feasibility and usability of P4 program verification are improved.

[0054] The present disclosure extracts complete control flow graph and data flow information structure based on P4 control structure and data dependency features. By analyzing all parser states, control blocks and matching action tables and the conditions and sequential relationships between them, the generated verification model corresponding to other target languages can fully reflect the logical behavior of the P4 program. At the same time, the definition-use dependency relationship between table entries is included in the model to ensure that the dependency constraints are considered, thereby avoiding the false positives or omissions caused by the traditional model ignoring such dependencies. For example, in error detection, if a field is modified in a table and used in a subsequent table, the data dependency structure of the present disclosure can ensure that such dependency relationship is reflected in the verification model, avoiding missing related paths.

[0055] The existing scheme simplifies the extraction of the control flow of the P4 pipeline too much, and usually regards it as a normal sequential program or a simple infinite loop. For example, bf4 models the P4 program as a stateless sequential process, and uses GCL and the weakest precondition for verification; P4Inv represents it as a while(true) loop, and verifies the state properties by inferring invariants. Such methods fail to accurately reflect the actual control structure of P4, resulting in the stage division, conditional branching and event-driven characteristics being ignored. Especially when it comes to Ingress / Egress multi-control blocks, table matching actions and the recirculate introduced loop path, the traditional model either ignores the branches or cannot distinguish different execution paths, causing the model to deviate from the real behavior. The present embodiment improves the control flow extraction process based on the above technical problems.

[0056] Figure 2 A flowchart of the first control flow graph construction method S110 of the embodiment of the present disclosure is shown. The following will be described in detail according to the flowchart. Figure 2 The steps in S110 will be described in detail.

[0057] In step S111, the first control flow graph is initialized, and an initial node is added as the program entry node (such as the ENTRY node) in the first control flow graph. The program entry node is the starting point of the entire control flow graph (which can be assigned a node ID=0, and the size of the node ID increases with the order of node addition, and the node with the largest ID is the latest added node), and is pushed into the maintained node stack after being created, and is set as the current node currentNodeId. The current node is updated according to the order of node addition in the subsequent steps, so as to ensure that the correct predecessor (i.e. the last node connected by the sequential edge) of the new node can be found when the new node is added.

[0058] In step S112, the top-level definition object set of the P4 program is traversed to find instances of the composite component type, and for each instance found, a sub-control flow graph of the instance is constructed in the first control flow graph, and the sub-control flow graphs of the instances are sequentially connected in the order of execution of the instances through sequential edges after the program entry node.

[0059] Exemplarily, the top-level definition object set of the P4 program is extracted through program->objects. After the top-level definition object set is extracted, for each pipeline instance declaration therein, it is determined whether the type thereof is a composite component. The composite component can be different instances according to specific applications, such as Pipeline, switch V1 model, etc. The embodiment takes Pipeline as an example for description.

[0060] In step S113, when the sub-control flow graph of the last instance is constructed, the last node in the sub-control flow graph of the last instance is marked as a program exit node.

[0061] P4 programs have some unique behaviors, such as recirculate and mirror, which introduce non-regular control flow and increase the difficulty of modeling. Recirculate means that the packet needs to be re-injected into the device pipeline, which is equivalent to creating a loop path in the data plane; mirror involves copying the packet during processing and sending it to other ports or the control plane. These behaviors break the straight-line flow of traditional sequential programs and exhibit event-driven and concurrent characteristics. Existing verification tools often use simplification strategies (such as using metadata markers instead of actual loops or mirror processes) because they have difficulty directly incorporating such non-linear flow into the model, which results in incomplete support for related features. Considering that existing P4 program verification or modeling tools lack complete support for specific behaviors such as packet recirculation (recirculate) and packet mirroring (mirror). For example, some methods only approximate these operations by setting metadata flags, without truly reflecting their impact on the pipeline flow. Similarly, for variable state elements such as data plane registers, existing tools often have only partial or simplified support and cannot fully model the read-write updates of registers. The above limitations result in incomplete model functionality, which may miss critical behaviors in scenarios involving these features. Therefore, in some embodiments, a sequential edge from the program exit node to the program entry node is added as a loopback edge for some special cases. For example, when operations such as recirculate (resubmit), resubmit (recirculate), clone (clone), or mirror (mirror) that cause the packet to re-enter the pipeline are detected during traversal, the corresponding flags isRecirculate, isResubmit, isMirror are set to true. At the end of traversal, if these flags are true, a sequential edge from the program exit node to the program entry node (node ID=0) is added, with the label "Program fallback" (program loopback). In this way, the control flow graph explicitly contains the control path of the pipeline loop, allowing for subsequent depiction of the possibility of secondary processing of the packet (e.g., the case of the packet re-entering the ingress). In some embodiments, regardless of the presence of the above operations (causing the packet to re-enter the pipeline), at least one default edge from the program exit node to the program entry node is usually added to ensure the completeness and reachability of the program flow graph. At this point, the control flow graph is complete, and the resulting control flow graph contains the program stages, statement nodes, and their sequential flow and control dependency relationships.

[0062] Correctly modeling recirculate and mirror semantics in P4 is another big challenge in the implementation. To represent packet recirculation, the model needs to allow a packet to re-enter the Ingress stage after completing a pipeline pass in the same device, which actually introduces an extra loop path in the model; while packet mirroring requires the model to generate a copy of the original packet and send it to a predetermined egress or control plane, bringing in an extra concurrent packet flow. Implementing these semantics requires special design in the model. The present invention unifies the handling of these features by introducing a "TrafficManager" component in the compiler model: when the Ingress logic decides to perform recirculation on a packet, the component sets a Recirculate flag so that the packet is sent back to the Ingress channel of the same device after completing the current processing; if the program calls a mirror operation, the component sets the mirror output port of the packet according to the mirror session configuration issued by the control plane, and generates a mirror packet header in the Deparser stage to send the duplicated packet out of the device. Special care is needed in the design of this mechanism: it must be ensured that the loop triggered by the Recirculate flag does not cause infinite packet looping (which can be controlled by limiting the number of loops for each packet or modeling the behavior of hardware queues), and the concurrent packet flow generated by Mirror is handled correctly to ensure that the sending order and queue of the original packet and the mirror packet in the model conform to the actual hardware semantics. The modeling of these special behaviors needs to be repeatedly verified for its rationality in terms of technology.

[0063] The present disclosure completes the construction of the first control flow graph through the above steps, and fully covers the control mode of the P4 program by explicitly modeling the full path of ENTRY→each stage→EXIT, ensuring the strong connectivity and path reachability of the control flow graph.

[0064] Figure 3 A flowchart of the sub-control flow graph construction method S112 of an example of an embodiment of the present disclosure is shown. The following will be described in detail according to the steps of S112. Figure 3 The steps of S112 will be described in detail.

[0065] In step S1121, a declaration node of the example is constructed in the first control flow graph, and the declaration node is connected by a sequential edge after the program entry node or the last node in the sub-control flow graph of the previous example. As a possible implementation, the declaration node represents the entire Pipeline instance, and the node type of the declaration node is marked as declaration type (DECLARATION).

[0066] In step S1122, according to the sub-components cited by the instance, a sub-control flow graph of each sub-component is constructed, and the sub-control flow graphs of the sub-components are sequentially connected through sequential edges in the order of execution of the sub-components in the instance after the declaration node of the instance, so that the sub-control flow graphs of the sub-components form a sequential execution relationship.

[0067] The types of the sub-components cited by the instance include a parser, an Ingress control, an Egress control, a Deparser, and the like. In order to facilitate subsequent construction of the instance control flow, in some embodiments, each instance-cited sub-component is recorded through a PipelineInfo structure.

[0068] It should be noted that in step S1122, only the structural information of the instance is collected, and the internal logic of the instance is not deeply analyzed.

[0069] Each instance in the P4 program is usually composed of a parser stage and a control stage: the parser stage is used to define the packet parsing state machine, and the control stage is used to define the pipeline processing logic. In some embodiments, after collecting the structural information of all instances, each PipelineInfo is processed by calling the buildPipelineInternals function. The processing process sequentially connects the parser and the control sub-components into the control flow graph in the order of the components defined by the pipeline. Through this mechanism, the parser, multiple controls are sequentially connected, and are connected through sequential edges, forming the control flow of the overall pipeline.

[0070] As another possible implementation, in the construction of the sub-control flow graph of a subcomponent, the following method is adopted: the phase node of the subcomponent is constructed in the first control flow graph, and the phase node is connected by a sequential edge after the declaration node of the instance to which the subcomponent belongs or the last node of the sub-control flow graph of the previous subcomponent, while the phase node is pushed into the node stack. According to each statement contained in the subcomponent, the sub-control flow graph of each statement is constructed, and the sub-control flow graphs of the statements are sequentially connected by sequential edges after the phase node of the subcomponent in the order of execution of the statements in the subcomponent; meanwhile, a control edge is constructed from the corresponding node at the top of the node stack to the statement entry node of the sub-control flow graph of each statement. When the sub-control flow graph of the last statement contained in the subcomponent is constructed, the phase node of the subcomponent is popped from the node stack. It should be noted that in the construction of the control edge corresponding to the subcomponent, it is necessary to point to the statement entry node in the sub-control flow graph corresponding to the statement. If the sub-control flow graph corresponding to the statement contains only a unique node (such as an assignment statement), the statement entry node is the unique node; if the sub-control flow graph corresponding to the statement is a control block, an action call, a conditional branch, etc., the statement entry node is the entry node of the control component in the corresponding sub-control flow graph.

[0071] In step S1123, an instance exit node of the instance is constructed after the last subcomponent, and a sequential edge is constructed from the last node in the sub-control flow graph of the last subcomponent to the instance exit node. The instance exit node represents the exit of the entire instance control flow.

[0072] The generation methods of the sub-control flow graphs of different types of statements will be introduced below.

[0073] (1) Assignment statement The assignment statement is the most basic type of statement, corresponding to the IR::AssignmentStatement node. In some embodiments, a CFG node of the Statement type is created for each assignment statement, and the name and code content of the node are a string in the form of "<left value> = <right value>;". For example, the assignment statement "x = y + 1;" will generate a node with the name "x = y + 1;" (hereinafter referred to as an assignment node), and the node type is marked as Statement. After the new node is created, it is connected to the end of the current basic block by a sequential edge (i.e., from the previous statement node (or block entry) to the assignment node), indicating the concatenation of the program execution flow. At the same time, the node stack is used to determine the control block to which the assignment statement belongs, and the top node of the upper stack is used as the source to point to the assignment node by a control edge, for identifying the belonging structure of the assignment statement (for example, recording which control block or code block the assignment statement belongs to).

[0074] During the construction of the assignment node, the variable definition and usage information of the assignment statement is also collected, and the full variable name corresponding to the left value of the assignment statement is added to the definition variable field genVars of the assignment node, indicating that the assignment statement "defines" the variable. For each variable or field involved in the right value expression of the assignment statement, its name is extracted and added to the usage variable field useVars, indicating that the assignment statement "uses" these variables. This Def-Use information is not necessary in the construction of the traditional control flow graph, but it provides support for subsequent data dependence analysis in this method. In short, after the extraction of the assignment statement, a single sequential node is generated and connected in the control flow, which does not involve branching inside, the ID of the previous node is sequentially extended, and the defined and used variables are marked. This processing logic is relatively direct and is the basis for the extraction of other complex control structures.

[0075] (2) Conditional branching statement (if-else) The extraction of the conditional branching statement (corresponding to IR::IfStatement) requires the introduction of multiple nodes to represent the branching structure and the merging relationship. The specific process includes: For each if statement, first create a conditional judgment node, set the node type to IF, and the name to "if (<condition expression>)", and record the text of the judgment condition in the code content. This conditional judgment node serves as a judgment point, with two sequential edges leading to the True and False two branch paths. In order to explicitly distinguish the branches, in some embodiments, a branch entry node is created for each branch of the if statement: the True branch entry node is named "if true", and the False branch entry node is named "else". The node type of the two branch entry nodes can be marked as CONDITION, indicating that this is a conditional branching node. The conditional judgment node is connected to the "if true" node and the "else" branch entry node through sequential edges, and the labels of the sequential edges used for connection are marked as "true" and "else" (or "false") to indicate the branch taken. The construction of the above control flow is equivalent to taking the if node as a decision point, branching out two different execution paths.

[0076] Subsequently, the then and else blocks of the if statement are processed respectively: when the True branch entry node is encountered, it is pushed onto the node stack to indicate the entry of the sub-block of the True branch, and then the statement list inside statement->ifTrue is recursively traversed, and CFG nodes are generated for each statement therein and connected in sequence according to the regular rules. After the traversal of the True branch is completed, the last generated node is the end node of the True branch (denoted as thenEnd). At this time, the True branch entry node is popped from the node stack to return to the condition judgment level, and a merge node (type MERGE) is created, for example, named "IfExit", to merge the control flows of the two branches. A sequential edge is added from thenEnd to the IfExit node to represent the direct flow from the end of the True branch to the merge node.

[0077] The False branch is then processed: if the if statement has an else block, it is processed in a similar way to the True branch, i.e., the False branch entry node is pushed onto the node stack to indicate the entry of the sub-block of the False branch, and the statement list inside statement->ifFalse is traversed, and CFG nodes are generated for each statement therein and connected in sequence according to the regular rules. After the last node of the False branch, elseEnd, is generated, the False branch entry node is popped from the node stack, and a sequential edge is added from elseEnd to the aforementioned IfExit merge node. If the if statement has no else block, in an implementation, an explicit "else” branch entry node (but with no statements inside) is still introduced in the CFG. This empty else branch entry node is directly connected to the IfExit merge node through a sequential edge, representing that the condition is false and no operation is performed when the merge point is reached. In this way, regardless of whether the if statement has an else block, the IfExit merge node has incoming edges from both paths.

[0078] Finally, after the sub-control flow graphs of the two conditional branches are both constructed, the condition judgment node is popped from the node stack, and the IfExit merge node is set as the current node, so that the nodes added subsequently can be sequentially connected after the entire if structure.

[0079] The whole conditional branch statement is composed of four types of nodes and corresponding sequential edges and control edges in the control flow graph, the four types of nodes including a conditional judgment node, a True branch node, a False branch node (which can be empty) and a confluence node. Such a design ensures that the control flow graph accurately represents the if-else semantics: it distinguishes the execution paths of the two branches, and through the confluence node, it reflects the convergence after the end of the branches. This kind of explicit confluence node simplifies the processing of branch convergence. In some embodiments, the confluence node can also be chosen not to be explicitly constructed, but directly converged through multiple predecessors. Compared with not explicitly constructing the confluence node, the explicit confluence node adopted in the present embodiment can make the control flow graph clearer, facilitating subsequent analysis.

[0080] (3) table.apply() table application statement In P4,

[0081]

[0082] <actionname>(<params...>);”, of type ACTION. The label can be annotated with the action name. Meanwhile, a control edge is used to connect the rule condition node as a parent node to the action invocation node. In this way, the "condition judgment -> action execution" of a specific rule forms a complete branch path. In the control flow graph, the Match node goes through the rule condition node and then to the action invocation node, representing the control flow of "if a certain matching condition is met, then execute the corresponding action". In an embodiment, when constructing the action invocation node, the action definition is further checked: if the action has a specific implementation (the body of IR::P4Action) in the P4 program, findActionDefinition is used to find the action IR, and processActionInstance is called to expand its internal logic. This is equivalent to the control flow of inlining the action, inserting the statement nodes inside the action into the control flow graph (the specific way is similar to processing an independent control block, see the nested control block section below). After the action is executed, the module records the exit node ID of the branch for subsequent merging.

[0083] If there is no explicit rule list (for example, the table key is empty or there is only a default action), the Match node does not need to split multiple condition branches. At this time, the default action path is directly processed.

[0084] Default branch and merge: Regardless of the rule list, a table lookup can have a default action branch. In one embodiment, the default action of a table is also added to the control flow graph by invoking a handleDefaultAction function: if the table has a matching key but does not match any of the explicit conditional rules, the default action is executed; or if the table has no key at all (it is executed entirely through the default action). handleDefaultAction creates a corresponding action invocation node (or a conditional node) to represent the default case, and makes it a successor of the Match node or the table invocation node. To uniformly represent the end of a branch, in one embodiment, a table exit (TableExit) node is created for the entire table application, e.g., named "TableExit()", with a MERGE type to represent a merge point. All rule branches are connected to this table exit node through sequential edges after their actions are executed. The default action path is also connected to this table exit node. In addition, if there is a Match node (for the case with a key), a direct sequential edge is added from the Match node itself to the table exit node to cover the "no rule is matched" path (which usually corresponds to the default action, and is implemented by handleDefaultAction to internally connect or through an empty rule transition). The table exit node serves as a merge point for the completion of the table processing: regardless of which table entry is matched and executed, the flow will eventually come to this node, and then continue with the subsequent pipeline control flow.

[0085] Tail and return: After the entire table application is processed, the current node is set to the TableExit node (indicating the end of the table processing). Then the context of the table invocation node that was pushed earlier is popped, and the control flow goes back to the outer control flow traversal. At this point, the original table.apply() statement is replaced by a series of control flow graph nodes: the table invocation node, the Match node, a number of rule condition nodes and action invocation nodes, and a merge table exit node, which completely describe the table lookup and action execution process. In the outer control flow graph, the sequential edge before the table invocation node is connected correctly, and the entire flow continues from the table exit node after the table invocation ends. In this way, any statement that follows table.apply() will have the table exit node as its predecessor (i.e., the node connected by a sequential edge), which is consistent with the semantic execution order.

[0086] In summary, table.apply() is factored into a subgraph of conditional branches. Note that the known table entries (e.g., rules obtained by BMV2CmdsAnalyzer) are utilized to explicitly construct the branches during factoring. This is optional in implementation: if no static rule information is available, one can just generate a Match node and a default action path, or treat the table as a black-box action. But to more accurately model the control flow, we choose to incorporate the rule branches (if available). This is particularly useful for checking the compiled program, because different rules lead to different paths, covering more state space.

[0087] (4) Special statements (recirculate / resubmit / exit / mirror, etc.) P4 language provides some special control flow operations, such as exit to exit the pipeline, resubmit to re-submit the packet to the ingress, recirculate to re-cycle the packet in the current pipeline, and clone / mirror to clone / mirror the packet. They have special effects on the control flow, and the module is specially processed during factoring.

[0088] Exit statement (exit): The exit statement indicates that the subsequent pipeline processing is immediately stopped. In the CFG, the module treats it as a special basic statement: create an exit node of type STATEMENT, named "exit;". The exit node is connected after the previous node by a sequential edge, indicating that when the execution reaches here, the flow jumps to the end of the pipeline. But unlike ordinary statements, there is no sequential successor after the exit node, because normal execution will not continue to the next statement. In order to reflect this on the control flow graph, we can choose to point the exit node to the exit node of the control or the exit node of the entire program through a sequential edge. In one implementation, a more direct approach can be taken: the exit node is still inserted in the control flow, but when building the program control flow graph, the program exit node and loopback logic handle the possible exit path (see recirculate processing below). In other words, when there is an exit statement, the exit leads directly to the end of the instance, and the edge from the exit node to the program exit or back to the entrance on the control flow graph implies this semantics. If strictly speaking, a control edge can be added directly from the exit statement to the exit node of the instance to explicitly indicate the termination of the instance. In general, the factoring result of the exit statement is an independent statement node, and its appearance means that the current control branch ends here; special processing will be done when converting to other programming languages (such as Promela) (e.g., triggering the end at the corresponding state).

[0089] Resubmit and Recirculate: These two operations cause the current packet to go through the ingress or the current pipeline again. In one embodiment, when a corresponding MethodCall is encountered (which can be identified by the method name "resubmit" or "recirculate"), an invocation node representing the call is inserted into the control flow graph, and a flag (e.g., isResubmit or isRecirculate) is set to true. The invocation node itself is connected to the normal flow by a sequential edge, as if it were a regular method call. At the end of the flow, a loopback edge is added based on the flag, i.e., after the program exits, if the flag is true, a sequential edge is added from the program exit node back to the program entry node. This sequential edge simulates the effect of resubmit / recirculate, i.e., the packet does not really end when it exits, but instead enters the pipeline again from the beginning. Thus, at the control flow graph level, a loop is created. Note that the above handling implies that the packet is allowed to go through the pipeline multiple times, if only one pass is allowed, the loopback edge is not added. Thus, the loopback edge is optional, depending on the modeling requirement; in the application scenario of this embodiment, to accurately cover the behavior of P4 runtime, the control flow loop is added.

[0090] Mirror / Clone: The mirror operation generates a copy of the original packet and sends it to a specified pipeline or port. For the control flow, the processing flow of the original packet is generally not affected (it continues to execute the remaining flow), while the copy will enter the pipeline separately. To take into account the accuracy of the method, in one embodiment, the mirror / clone operation is treated similarly to recirculate when it is extracted, i.e., when a mirror / clone call is detected, a flag (e.g., isMirror) is also set to true. In this way, at the program exit, a loopback edge is also added to simulate the path of the mirrored packet entering the pipeline. Note, however, that strictly speaking, the new flow caused by mirror is not a loop of the original flow, but rather it is executed in a parallel pipeline (e.g., egress or a special mirror pipeline). In this embodiment, the difference is not distinguished in detail, but is simply treated as a case of re-entry and handled uniformly. This is a trade-off at the model abstraction level: when converted to other programming languages, the processing of the mirrored packet can be represented by adding a path similar to recirculate. If necessary, a more accurate approach can be to generate a separate entry node or a specially marked path for mirror. In this embodiment, the framework for control flow extraction is emphasized, so the simplified handling of flag + loopback edge is adopted in the implementation.

[0091] In summary, the processing of special statements is throughout the whole process of control flow extraction: when these special statements or method calls are found while traversing the IR, the corresponding nodes are generated and the flags are recorded on the fly, instead of being remedied after the traversal is finished. This ensures that the control flow graph is aware of the special flow transitions during its construction. For example, when a resubmit node is added in the middle of the construction of the control flow graph, a loop edge is generated during the phase of connecting the program exit nodes, so that there is a path from the resubmit node back to the pipeline start node (i.e. the program entry node). This control dependency reflects the influence of these special operations on the control flow. It is emphasized that the nodes such as exit, resubmit, recirculate nodes themselves are usually classified as general STATEMENT (or specific identified nodes) in the control flow graph, but the control flow changes triggered by them need to be described by additional edges, which is the enhancement of the present embodiment relative to the ordinary control flow graph generation. By the above special statements, the subsequent target language corresponding verification model can cover all possible loop processing situations, and the completeness of verification is guaranteed. In combination with the above loop modeling method, the present application can find security or logic vulnerabilities caused by repeatedly processing the same data packet, thereby improving the robustness of model checking.

[0092] (5) Block statement and nested control block A block statement (BlockStatement) is a group of statements enclosed in braces, which can appear in the body of a control, inside a conditional branch, in the implementation of an action, etc. In an embodiment, for each block statement, a block enter (BlockEnter) node and a block exit (BlockExit) node are created to explicitly indicate the entering and leaving of the scope of the block statement. For example, when a compound statement {...} is encountered, a block enter node is generated when entering, and a block exit node is generated when exiting. The block enter node is usually marked as BLOCK, and the name can be simply recorded as "BlockEnter". The block exit node is usually marked as EXIT or can be specially identified. In the control flow graph, the current execution flow order edge points to the block enter node (meaning entering the block), and then the module pushes the block enter node into the node stack as the new control context. Then each statement in the block is traversed, and the processing logic of each statement is the same as the above-mentioned method (possibly recursively appearing new blocks, conditions, etc.). These internal statement nodes are connected to each other in sequence by sequential edges. After the last statement in the block is processed, the corresponding control flow graph node is the last node of the block. At this time, the block exit node is created, and a sequential edge is added from the last node to the block exit node. Then the block enter node is popped from the node stack to restore the upper control context, and the block exit node is set as the current node to continue from the end of the block.

[0093] By the encapsulation of the block entry and exit nodes, each statement block becomes a well-bounded subgraph in the control flow graph, ensuring the block scope can be reflected when converted to other programming languages (e.g. for variable lifetime management or single-step debugging).

[0094] Nested control blocks refer to the case when a control block is invoked or entered in another independently defined code block. In P4, the most typical cases are action invocation and action execution in table invocation. For example, when an action invocation such as some_action(); is encountered (usually represented as a MethodCallStatement in IR and parsed as an ActionCall), the processing logic is to treat this as entering a new control block. In implementation, an action invocation node (name contains the action and arguments) is created first, connected to the current flow with a sequential edge, and pushed to the stack as the action execution context. Then the definition of the action, IR::P4Action, is looked up, and visit(action->body) is called to enter the action implementation. The statements in the action are processed similarly to the control body, and block statements, conditional branching statements, etc. can appear again inside the action, which are expanded according to the previous rules. After all the statements in the action are processed, the action invocation node is popped and the execution returns, leaving the expanded subgraph of the action invocation in the control flow graph. This way of inlining the nested action logic in the control flow graph makes it unnecessary to handle the independent action invocation process separately, but instead treats it as part of the control flow. Similarly, for the state transitions inside the parser subcomponent, which are essentially nested structures (parser calls the next state similar to invoking a sub-process), we can build subgraphs for each ParserState in the parser traversal and connect them through the aforementioned ParserTransition records.

[0095] Through the above mechanism, no matter what level of nested control, can be uniformly extracted as a subgraph (i.e. sub-control flow graph), that is, an entry node is constructed when entering, an exit node is constructed when exiting, and the middle is connected according to the respective statement rules order / branch. It should be noted that this processing does not depend on specific language features and can be generally applied to nested process calls, function calls and other situations. Therefore, the control flow graph conversion method proposed in this embodiment has certain universality. For P4, we clearly distinguish the entry / exit nodes of different syntax components such as parser, control, action, table, and associate them with the upper layer structure containing them using control edges. For example, the table apply node is connected with the control it is in through a control edge, and the action call node is connected with its parent node (which may be a table rule or directly in the control) through a control edge. These control edges do not represent the actual execution order in the control flow graph, but indicate a hierarchical affiliation relationship, which helps to clarify the control dependency structure within the program.

[0096] Figure 4 A flowchart of the data dependency edge construction method S120 of the embodiments of the present disclosure is shown. The following will be described in detail according to the data dependency edge construction method S120 of the embodiments of the present disclosure. Figure 4 The steps in S120 will be described in detail.

[0097] In step S121, the nodes in the first control flow graph are traversed, and the definition variable set (defSet) and the use variable set (useSet) of each node are extracted.

[0098] The set of defined variables corresponds to the genVars and useVars fields in the CFGNode structure. Whenever a statement is encountered, the analysis program extracts its left-hand side (the variable being assigned or declared) into defSet and all variable names involved in its right-hand side expression into useSet. For example, for the assignment statement x = y + 1, x is added to defSet and y to useSet; for a variable declaration such as int n = m, n is added to defSet and m to useSet. For composite variables involving field access, in some embodiments the variable is represented using its fully qualified name, e.g., a structure or packet header field using ".” to concatenate the hierarchical names (hdr.ipv4.srcAddr), and an array element using "[...]" to represent the subscript. With the help of a reference map (ReferenceMap) and a type map (TypeMap), it is possible to locate a member access or array index in the IR and convert it into a unique string identifier (via functions such as Utils::getFullVariableName). Note that in some special cases, the variable name is simplified, e.g., for read and write operations on P4 state registers, since the register array has persistent state, the register name plus the wildcard subscript "[]” is treated as an abstract variable for the entire register for dependency tracking, and the index itself is added to useSet as an independent variable name. In this way, even if different locations access the same register using different indices, it is recognized as a read and write to the same state. As another example, setting the valid bit of a packet header, header.valid, is treated as a definition of the corresponding header valid bit field. Note that the above embodiments directly perform dependency analysis based on the variable names of the source program and do not perform SSA (Single Static Assignment) form conversion. Unlike SSA, we do not rename variables for each assignment, but still use the original variable names to establish def-use relationships. This means that a variable can have multiple definitions, and the actual dependency relationship needs to be determined through a reaching definition analysis, while in the SSA form each use is directly associated with a unique definition.

[0099] In step S122, the use variable set of each node is traversed, and for each use variable in the use variable set of the current node, all the definition variables matched therefrom are searched from the definition variable set of other nodes, and all the nodes where the found matched definition variables are located are taken as candidate definition nodes of the current node.

[0100] In some embodiments, a reaching definition set RDin (definition set reaching the node) and a flowing out definition set RDout (definition set flowing out of the node) are also constructed for each node. The reaching definition set RDin and the flowing out definition set RDout can be constructed by an iterative dataflow analysis method, i.e. first initializing the reaching definition set RDin and the flowing out definition set RDout for each node, then repeatedly updating the RDin of the current node by aggregating the RDout of the predecessor nodes, and applying the kill / gen rules: removing the old definitions of the variables that are redefined in the current node (eliminating the previous definition of the same variable), and adding the new definitions generated in the current node to the RDout. Through iteration until convergence, all possible definition sets carried in the reaching definition set RDin of each node are obtained.

[0101] When the reaching definition set RDin and the flowing out definition set RDout are completed, the use variable set useSet of each node is traversed, and for each use variable in the definition variable set useSet, all variables matching the variable (i.e. finding the definition source of the variable) are found in the reaching definition set RDin of the node. All variables found in the reaching definition set RDin are regarded as candidate definitions of the variable, and according to each candidate definition, all variables with the same variable name are found from all flowing out definition sets RDout, and the node of the variable with the same variable name is taken as a candidate definition node.

[0102] In some embodiments, when finding all variables matching the variable, it is provided that the variable names are the same or there is a prefix or suffix containing relationship, which are all judged to match. For example, a special logic of field prefix matching is used to handle the cases of nested fields and chained access: if a definition variable name contains a use variable name, or vice versa (for example, the definition hdr. ipv4 contains the use hdr. ipv4. srcAddr, or the definition meta. array [idx] contains the use meta. array), it is considered that both refer to the same logical variable, and is judged to match, so that a dependency link is established. In this way, it can be ensured that the data dependency relationship between the overall assignment of a structure or a message header and the field access thereof, and between the array as a whole and the element, will not be missed.

[0103] In step S123, for each candidate definition node, a directed edge from the candidate definition node to the current node is created as a data dependency edge.

[0104] In some embodiments, the variable name tag can be attached to the data dependency edge to indicate the dependent variable.

[0105] It should be noted that for the case of dependencies across control flow loop or pipeline iteration, the following processing is adopted: when it is allowed to connect the tail of the control flow graph (program exit node) with the head (program entry node) to form a loop (i.e. to construct a loopback edge), there can be a "reverse" data flow that defines a node ID greater than the node ID that uses it (e.g. for simulating the loop processing of a data packet, recirculate, etc.). Such cross-iteration dependencies are only preserved in the case of persistent variables (such as packet header instances or registers, which retain state across iterations); for general temporary variables, the cross-iteration dependency is ignored.

[0106] Through the above steps, a complete set of variable definition-to-use dependency relationships is constructed, and corresponding data dependency edges are added to the control flow graph. The data dependency edges in the control flow graph represent the influence of the variables defined by the source node statement on the target node statement, thereby clearly representing the value transmission and data flow process within the program.

[0107] In some embodiments, when multiple candidate definitions of a used variable are found, a filtering of all the found candidate definition nodes is further included, and only the filtered candidate definition nodes are used when creating data dependency edges.

[0108] In some embodiments, the purpose of the filtering is to select the latest and context-matched candidate definition, and the specific implementation includes: comparing the positions of all candidate definition nodes in the control flow graph, and selecting the candidate definition node with the largest node ID (indicating the definition closest to the use in the program execution path), while extracting other definition nodes in the same control flow branch or scope as the current node (i.e. the node in which the used variable is located). Through this "nearest preceding definition" strategy, it can be ensured that the use node is only connected to the actual reachable and latest definition in the program running, avoiding interference from premature definitions from different branch paths.

[0109] Figure 5 A block diagram of a P4 program compiling electronic device is shown according to an example embodiment of the present disclosure. As shown in Figure 5 As shown, the present disclosure provides a P4 program compiling electronic device 1000, which can include: a control flow extraction module 1002 configured to convert a P4 program into a first control flow graph; a data dependency relationship construction module 1004 configured to construct data dependency edges in the first control flow graph according to the matching relationship between definition variables and used variables, to generate a second control flow graph; and a translation module 1006 configured to convert the second control flow graph into a program corresponding to a target language according to translation rules between elements of the P4 language and corresponding elements of the target language, control edges and data dependency edges.

[0110] The hardware structure of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnecting buses and bridges, depending on the specific application of the hardware and on overall design constraints. The bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules together. The bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc. The bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one connection line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0111] For ease of illustration, some steps of the above method are described in correspondence with modules. It should be understood that the corresponding module performing one or more steps of the above method can be one or more hardware modules specially configured to perform the corresponding steps, or implemented by a processor configured to perform the corresponding steps, or stored in a computer readable medium for implementation by a processor, or implemented by some combination.

[0112] The present disclosure also provides a readable storage medium having a computer program stored therein, the computer program being executed by a processor to implement the above method. The "readable storage medium" can be any device that can contain, store, communicate, propagate or transport programs for use by or in conjunction with an instruction execution system, apparatus or device. More specific examples of readable storage media include the following: an electrical connection having one or more wires (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM), etc.

[0113] The present disclosure also provides a computer program product, and the method of the present disclosure can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, the flow or function of the present disclosure is executed in whole or in part.

[0114] The computer program or instructions can be stored in or transferred from one computer-readable medium to another, e.g., from one website or computer to another website or computer, by way of wired or wireless communication. The computer-readable medium can be any available medium or a combination of one or more of the available media that can be accessed by a server, data center, or the like, and includes both volatile and nonvolatile media, removable and non-removable media. The computer-readable medium can be a magnetic medium, e.g., a floppy disk, a hard disk drive, a magnetic tape; optical media, e.g., a compact disc, a DVD, etc.; or a semiconductor medium, e.g., a solid-state drive. The computer-readable medium can be a volatile or non-volatile medium, or can include both volatile and non-volatile media.

[0115] Those skilled in the art will appreciate that embodiments of the disclosure can be supplied as a method, a system, or a computer program product. Accordingly, the disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the disclosure can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage media, etc.) embodying computer-readable program code.

[0116] The disclosure is described with reference to the drawings using a flowchart and / or a block diagram of methods, electronic devices, and computer program products according to the disclosure. It will be understood that each block of the flowchart and / or block diagram, and combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing device, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 The flowchart and / or block diagram can include one or more flowcharts and / or one or more block diagrams. Figure 1 The flowchart and / or block diagram can include one or more flowcharts and / or one or more block diagrams.

[0117] The computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart and / or block diagram block or blocks. Figure 1 The flowchart and / or block diagram can include one or more flowcharts and / or one or more block diagrams. Figure 1 The flowchart and / or block diagram can include one or more flowcharts and / or one or more block diagrams.

[0118] These computer program instructions can also be loaded into a computer or other programmable data processing devices, so that a series of operational steps are performed on the computer or other programmable data processing devices to generate computer-implemented processes, thus the instructions executed on the computer or other programmable data processing devices provide the function of implementing the processes specified in the flowchart Figure 1 one or more flows and / or blocks Figure 1 one or more blocks or steps of the functions specified in the flowchart

[0119] Those skilled in the art should understand that the above-mentioned embodiments are only for clearly illustrating the present disclosure, and are not intended to limit the scope of the present disclosure. Based on the above disclosure, other changes or modifications can also be made by those skilled in the art, and these changes or modifications are still within the scope of the present disclosure.< / actionname> The apply() call is an important structure in the control flow, which can be viewed as a multi-branch selection (similar to switch-case, matching items according to a table to select different actions to execute). In an embodiment, the extraction of the table application is divided into two steps: first, identify whether the MethodCallStatement is the apply call of the table, and second, expand the matching branch of the table and the action execution flow. Specifically, when traversing the method call statement, the MethodInstance is determined by the type mapping, and if it is detected that it is a call to the apply() method of IR::P4Table, the special processing logic for table application is switched to. The processing process of the table application statement includes: table call node: create a table call node for the whole table.apply() statement, for example, named "Apply()", and the node type is recorded as TABLE or ACTION (ACTION is used to represent an action call in the implementation). The table call node indicates the start of the table lookup operation. The table call node is sequentially connected to the current control flow, and is connected to the control block structure through the control edge. Then, the table call node is pushed to the stack as the new current context, and the corresponding IR::P4Table definition visit(table) is further processed. In this way, the internal matching process of the table will be expanded into a subgraph in the control flow graph, and properly connected with the external process. Match branch expansion: after entering the preorder(const IR::P4Table* table) processing, first obtain the key information in the table definition: table name, matching key list, action list, etc. Then create a Match (match) node to represent the table matching condition check. The name of the Match node can contain information about all matching fields and matching types, such as "Match on hdr.ipv4.dstAddr (exact)". The Match node type uses CONDITION to represent the condition judgment point. The Match node is hung under the current table call node through the control edge, and is inserted as the sequential successor (i.e. the table call node sequentially points to the Match node through the sequential edge). At this time, the sequential edge of the table call node->Match node is equivalent to entering the table lookup flow. If the table definition has one or more keys (key), the Match node serves as the head node of the conditional branch. For each possible matching result (i.e. each table item rule, and the default case), a conditional branch path needs to be embodied in the control flow graph. The specific processing method is: check whether the compiler or runtime provides specific table item rules (for example, obtain the list of statically added rules through a BMV2CmdsAnalyzer). If the table item rules are provided, each table item rule is processed one by one: for each table item rule, create a rule condition node to represent "if the condition of the rule is matched".For example, for the match condition hdr.ipv4.dstAddr == 10.0.0.1, the generated rule condition node is named if (hdr.ipv4.dstAddr == 10.0.0.1) and is marked as a CONDITION. This rule condition node is made the sequential successor of the Match node (successor means a node connected by a sequential edge, i.e., the Match node points to this rule condition node by a sequential edge), and the label of the sequential edge is marked as the corresponding match value (to distinguish different rule branches). Then, for the action defined by this condition rule, an action invocation node is created, named like ". < / name>

Claims

1. A program compiling method characterized by comprising: The method comprises the following steps: Converting a P4 program into a first control flow graph; The edges in the first control flow graph comprise control edges for representing control relationships, and the node attributes in the first control flow graph comprise defined variables and used variables; the defined variables are variables defined in the statement corresponding to the node; The used variables are variables used in the statement corresponding to the node; According to the matching relationship between the defined variables and the used variables, a data dependency edge is constructed in the first control flow graph to obtain a second control flow graph; the data dependency edge is from the node where the defined variable is located to the node where the used variable matched with the defined variable is located; According to the translation rules between the elements of the P4 language and the corresponding elements of the target language, the control edges and the data dependency edges, the second control flow graph is converted into a program corresponding to the target language.

2. The method of claim 1, wherein: The method for converting a P4 program into a first control flow graph comprises the following steps: An initial node is constructed in the first control flow graph as a program entry node; A top-level definition object set of the P4 program is traversed to find instances of a composite component type, and for each found instance, a sub-control flow graph of the instance is constructed in the first control flow graph, and the sub-control flow graphs of the instances are sequentially connected in the order of execution of the instances after the program entry node through sequential edges; the sequential edges are used to represent sequential relationships; When the sub-control flow graph of the last instance is constructed, the last node in the sub-control flow graph of the last instance is marked as a program exit node.

3. The method of claim 2, wherein: The method for constructing the sub-control flow graph of the instance in the first control flow graph comprises the following steps: A declaration node of the instance is constructed in the first control flow graph, and the declaration node is connected after the program entry node or the last node in the sub-control flow graph of the previous instance through a sequential edge; According to each sub-component referenced by the instance, a sub-control flow graph of each sub-component is constructed, and the sub-control flow graphs of the sub-components are sequentially connected after the declaration node of the instance in the order of execution of the sub-components in the instance through sequential edges; An instance exit node of the instance is constructed after the last sub-component, and a sequential edge is constructed from the last node in the sub-control flow graph of the last sub-component to the instance exit node.

4. The method of claim 3, wherein: The method for constructing the sub-control flow graph of the sub-component comprises the following steps: A node stack is initialized to record the starting points of the control edges used in the construction process; A stage node of the sub-component is constructed in the first control flow graph, and the stage node is connected after the declaration node of the instance to which the sub-component belongs or the last node of the sub-control flow graph of the previous sub-component through a sequential edge, and the stage node is pushed into the node stack; According to each statement contained in the sub-component, a sub-control flow graph of each statement is constructed, and the sub-control flow graphs of the statements are sequentially connected after the stage node of the sub-component in the order of execution of the statements in the sub-component through sequential edges; meanwhile, a control edge is constructed from the node corresponding to the top of the node stack to the statement entry node of the sub-control flow graph of each statement; When the sub-control flow graph of the last statement contained in the sub-component is constructed, the stage node of the sub-component is popped from the node stack.

5. The method of claim 4, wherein: When the type of the statement is recommit, recirculation, mirror or clone, the method for constructing the sub-control flow graph of the statement comprises: constructing a call node of the recommit, recirculation, mirror or clone statement, and adding a call flag field in the node attribute of the call node, and setting the value of the call flag field to true; after the construction of the program exit node is completed, detecting whether the value of the call flag field corresponding to the call node is true, and if so, constructing a sequential edge from the program exit node to the program entry node.

6. The method of claim 4, wherein: When the type of the statement is a block statement, the method for constructing the sub-control flow graph of the statement comprises: constructing a block entry node as the statement entry node of the block statement and pushing the block entry node into a node stack; according to each statement contained in the block statement, constructing the sub-control flow graph of each statement, and connecting the sub-control flow graphs of the statements in sequence after the block entry node through sequential edges in the order of the execution of the statements in the block statement, while constructing a control edge from the node corresponding to the top of the node stack to the statement entry node in the sub-control flow graph of each statement; after the construction of the sub-control flow graph of the last statement contained in the block statement is completed, popping the block entry node from the node stack; constructing a block exit node and connecting the block exit node through a sequential edge after the last node of the sub-control flow graph of the last statement.

7. The method of claim 1, wherein: According to the matching relationship between the defined variables and the used variables, constructing a data dependency edge in the first control flow graph comprises: traversing the nodes in the first control flow graph, and extracting the defined variable set and the used variable set of each node; traversing the used variable set of each node, for each used variable in the used variable set of the current node, searching for all the defined variables matched with the used variable from the defined variable set of other nodes, and taking the nodes where all the matched defined variables are located as the candidate definition nodes of the current node; for each candidate definition node, constructing a directed edge from the candidate definition node to the current node as a data dependency edge.

8. The method of claim 7, wherein: After taking the nodes where all the matched defined variables are located as the candidate definition nodes of the current node, further comprising: screening all the candidate definition nodes, and using the screened candidate definition nodes to construct data dependency edges; the screening method comprises: selecting the candidate definition node with the latest construction time from all the candidate definition nodes; and selecting the candidate definition node in the same control flow branch or scope as the current node from all the candidate definition nodes.

9. An electronic device, comprising: comprises: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, so that the processor executes the program compilation method in any one of claims 1 to 8.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the program compilation method in any one of claims 1 to 8. The computer program is executed by the processor to implement the program compilation method in any one of claims 1 to 8.

Images