PLC programming language program parallel detection method based on deep learning

Abstract

The invention discloses a PLC programming language program parallel detection method based on deep learning, and the method comprises the steps: firstly converting a PLC programming language into IR code representation, marking the IR code representation according to parallelization and non-parallelization, and generating a bidirectional function association graph to form a graph data set; secondly, obtaining a matching type label of each node based on the graph data set, constructing a parallelization detection model based on a graph embedding algorithm and a link dynamic graph LDGCNN model, and detecting whether the model is parallel or not; and finally, calculating a complexity numerical value for the code snippets, representing the IR codes with the complexity numerical value exceeding a set threshold value, identifying the IR codes through the trained LDGCNN model, and if an identification result is to be parallel, reserving header files and related variable definitions of the code snippets, and splitting the code snippets to obtain parallel programs. The parallel programming development cost is reduced, the parallel program processing efficiency and reliability are improved, and the error probability is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer PLC programming language program parallelization, and in particular to a program parallel detection method based on deep learning. Background Art

[0002] In recent years, high-performance computing technology has developed rapidly, especially in data-intensive scientific computing fields such as climate simulation and seismic data processing. Parallel computing technology has become the key to solving problems with high complexity, large data volumes, and long execution cycles. However, most traditional program parallelism analysis tools and compilation optimization technologies still have limitations when processing complex programs, and are not suitable for PLC programming languages ​​and cannot fit the characteristics of PLC programming languages ​​well. Although hardware platforms (such as multi-core processors, GPUs, etc.) already support parallel computing, a large number of applications are still designed in serial format and fail to fully utilize these hardware resources.

[0003] Traditional program parallelization methods mostly rely on manual analysis of data dependencies and control dependencies, or obtaining program features through static analysis and dynamic analysis. However, these methods are not effective when dealing with large-scale data-intensive applications. In recent years, deep learning technology has achieved remarkable results in natural language processing, image recognition and other fields, and has gradually been applied to semantic analysis and dependency identification of program codes. Based on this, how to use deep learning technology to improve the parallel identification and development efficiency of serial programs has become an important research direction. Summary of the invention

[0004] The purpose of the present invention is to provide a PLC programming language program parallel detection method based on deep learning, by constructing a parallelism recognition model to improve the parallelism recognition accuracy of serial programs and simplify the parallel development process.

[0005] The method proposed by the present invention specifically includes the following contents:

[0006] Step S1: Collect multiple open source code libraries and general algorithm implementation programs, convert PLC programming languages ​​into IR code representations, and then annotate the IR code representations according to the standards of parallelization and non-parallelization. Finally, generate a BFDG (bidirectional function dependency graph) to form a graph dataset composed of BFDG (bidirectional function dependency graph).

[0007] The specific process of generating BFDG (bidirectional function dependency graph) is as follows:

[0008] Phase 1:

[0009] 1. Initialize the graph structure: Create a global root node and use it as the starting point. Other irrelevant identifiers (such as global variables, basic blocks, etc.) are connected to the root node.

[0010] 2. Traverse each line of statement in the IR code representation: process according to the statement type and obtain nodes and edges.

[0011] 3. Store the constructed nodes and edges in a temporary document. The edges are represented in the format of [(node1,node2),statement], where node represents the node and statement represents the edge.

[0012] Phase 2:

[0013] 1. Construct nodes. The nodes in the BFDG (bidirectional function dependency graph) include: all nodes stored in phase 1 (i.e. identifiers, basic blocks, methods, etc.); function entry and exit nodes: each function entry and exit has a separate node.

[0014] 2. Build edges. (1) Control flow edges. Function call: A function call generates an edge from the call point to the entrance of the called method; return statement: A return statement generates an edge from the method exit to the caller. Branch instruction: For conditional jump statements, edges need to be established between branch target basic blocks. (2) Data flow edges. Dependencies between identifiers: For example, in a variable assignment statement, a data flow edge is added between the source identifier and the target identifier; cross-function data dependency: For method calls or return values, if the method call involves parameter passing or return value passing, a data flow dependency edge is established.

[0015] 3. Store the constructed nodes and edges in a temporary document. The edges are represented in the format of [(node1,node2),statement].

[0016] Step S2: Preprocess the graph data set: match the appropriate type label for each node in the BFDG (bidirectional function dependency graph) through regular matching; use Struc2Vec (graph embedding algorithm) to perform graph embedding training on the BFDG (bidirectional function dependency graph), and use the embedding result as the feature vector of the node. Build an LDGCNN (link dynamic graph) model, combine the type label and the feature vector of the node to obtain a new feature graph, input it into the LDGCNN model for training, output whether it is parallel, and train it.

[0017] Step S3: Calculate the complexity value for the code snippet.

[0018] Step S4: The IR code representation with a complexity value exceeding the set threshold is used to identify the code fragment through the trained LDGCNN model. If the recognition result is to be parallelized, the header file of the code fragment and the related variable definition are retained, and the code fragment is split to obtain a parallel program.

[0019] Furthermore, the main sources of datasets are divided into benchmark programs, existing mathematical operation program libraries, and general programs.

[0020] Furthermore, BFDG (Bidirectional Function Dependency Graph) is a graph structure representation that contains both program data flow information and control flow information. Each node represents an LLVM IR statement. Before forming the BFDG (Bidirectional Function Dependency Graph), the IR code representation needs to be processed, and then the control dependencies and data dependencies between nodes are integrated to generate a directed multigraph representation of the BFDG (Bidirectional Function Dependency Graph).

[0021] Furthermore, to calculate the complexity value for a code snippet, it is necessary to calculate from multiple dimensions such as program size, data flow, control flow, code type, etc., and multiply them by the corresponding weights respectively, and finally accumulate them to get the complexity value.

[0022] Furthermore, the model used to extract parallel code snippets is the linked dynamic graph convolutional neural network LDCGNN. The overall structure of the network mainly consists of a four-layer feature extraction layer, a fully connected layer, a maximum pooling layer, and finally an MLP (multi-layer perceptron) aggregation to output a list of prediction results.

[0023] Beneficial effects of the present invention:

[0024] Use Struc2Vec (graph embedding algorithm) and DGCNN (linked dynamic graph) model methods to more efficiently identify parallelizable code snippets, reduce parallel programming development costs, and reduce the burden on developers.

[0025] A parallel programming method is provided for the field of PLC graphic programming, and a complexity measurement method is introduced to improve the processing efficiency of parallel programs.

[0026] By constructing a BFDG (bidirectional function dependency graph), the association between program contexts is better captured, more association information is retained, and the parallel program processing effect is improved.

[0027] The standardized model training process improves the reliability of parallel programs and reduces the probability of errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 The algorithm flow chart for constructing BFDG (Bidirectional Function Dependence Graph);

[0029] Figure 2 This is the overall flow chart of data preprocessing;

[0030] Figure 3 This is a parallel comparison chart of ST codes. DETAILED DESCRIPTION

[0031] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the protection scope of the present invention.

[0032] A parallel detection method for PLC programming language programs based on deep learning, such as Figure 1 As shown, the method comprises the following steps:

[0033] Step S1: Collect data to form a data set, convert the PLC programming language into IR code representation, and then annotate the data with the standards of recommending parallelization and not recommending parallelization. Finally, generate a BFDG (bidirectional function dependency graph) to form a graph data set composed of BFDG (bidirectional function dependency graph).

[0034] Step S2: Preprocess the graph data set: match the appropriate type label for each node in the BFDG (bidirectional function dependency graph) through regular matching; use Struc2Vec (graph embedding algorithm) to perform graph embedding training on the BFDG (bidirectional function dependency graph), and use the embedding result as the feature vector of the node. Build an LDGCNN (link dynamic graph) model, combine the type label and the feature vector of the node to obtain a new feature graph, input it into the LDGCNN model for training, and output whether it is parallel.

[0035] Step S3: Calculate the complexity value for the code snippet.

[0036] Step S4: The IR code representations whose complexity values ​​exceed the set threshold are used to identify the code fragments through the trained LDGCNN (Linked Dynamic Graph) model, and the header files and related variable definitions of the files identified as the codes that need to be parallelized are retained, and the identified parallelizable code fragments are split to obtain parallelizable programs.

[0037] Example:

[0038] Step S1: Collect data to form a data set, convert the PLC programming language into IR code representation, and then annotate the data with the standards of recommending parallelization and not recommending parallelization. Finally, generate a BFDG (bidirectional function dependency graph) to form a graph data set composed of BFDG (bidirectional function dependency graph).

[0039] The main sources of the data set are benchmark programs, existing mathematical operation program libraries, and general programs. The benchmark programs mainly consider the Livermore loops and NAS parallel benchmark programs (NPB) used in most program parallelism related research. The mathematical operation program library uses the GNU high-precision arithmetic operation library GMP, the basic linear algebra subroutine library BLAS, and the program library that effectively supports linear algebra, matrix and vector operations, numerical analysis and related algorithms. The general program comprehensively considers the codes of classic parallel routines, matrix operations, graph and tree related algorithms, dynamic programming related algorithms, and some codes that are frequently used in the laboratory. And the code is converted into IR code representation.

[0040] An LLVM IR statement generally consists of seven parts: output variable identifier, IR instruction, operation data type, input variable identifier, other parameters, metadata, and comments. In order to simplify the construction process, the following preprocessing operations need to be performed on the LLVM IR file: (1) Constructor list: For each file, construct a list for storing all function names declared in the file, which is used to identify the functions declared in this file during the BFDG (bidirectional function dependency graph) construction process; (2) Delete the content that does not belong to the IR statement; (3) Cancel indentation and blank lines; (4) Delete the metadata at the end of the line;

[0041] (5) Combine multiple statements into one line.

[0042] The core of data labeling is to assign a category label to each piece of collected data, so that the label becomes an indispensable part of the data set. In the implementation of this method, the Pluto compiler is first used to start the loop decomposition operation, during which the potential parallelism between the outer loop and the inner loop is deeply explored. For those loop fragments that meet the parallel conditions, the "#pragma omp parallel..." compilation guide statement is added where appropriate. At the same time, the files that failed to be converted are properly maintained and manually re-annotated for these failed files. Subsequently, the compiler is enabled. The Advisor XE tool performs secondary analysis and judgment on the processed files. The results of manual annotation and judgment are carefully compared with those of the tool. For files with consistent results, they are absorbed and integrated according to their specific categories; for files with different results, they are directly discarded to ensure the accuracy and efficiency of data processing.

[0043] Figure 1To construct an algorithm flow chart of BFDG (Bidirectional Function Dependency Graph), the steps include: analyzing the control flow and data flow of embedded program code; generating an intermediate representation independent of the hardware architecture based on the LLVM compilation framework; integrating the control dependency and data dependency between nodes based on IR to generate a BFDG (Bidirectional Function Dependency Graph) represented by a directed multigraph.

[0044] The specific process of generating BFDG (bidirectional function dependency graph) is as follows:

[0045] Phase 1:

[0046] 1. Initialize the graph structure: Create a global root node and use it as the starting point. Other irrelevant identifiers (such as global variables, basic blocks, etc.) are connected to the root node.

[0047] 2. Traverse each line of statement in the IR file: process according to the statement type and add nodes and edges.

[0048] 3. Store the constructed nodes and edges in a temporary document. The edges are represented in the format of [(node1,node2),statement].

[0049] Phase 2:

[0050] 1. Construct nodes. The nodes in the BFDG (bidirectional function dependency graph) include: all nodes stored in phase 1 (i.e. identifiers, basic blocks, methods, etc.); function entry and exit nodes: each function entry and exit has a separate node.

[0051] 2. Build edges. (1) Control flow edges. Function call: A method call generates an edge from the call point to the entry of the called method; return statement: A return statement generates an edge from the method exit to the caller. Branch instruction: For conditional jump statements, edges need to be established between branch target basic blocks. (2) Data flow edges. Dependencies between identifiers: For example, in a variable assignment statement, a data flow edge is added between the source identifier and the target identifier; cross-function data dependency: For method calls or return values, if the method call involves parameter passing or return value passing, a data flow dependency edge is established.

[0052] 3. Store the constructed nodes and edges in a temporary document. The edges are represented in the format of [(node1,node2),statement], where node represents the node and statement represents the edge.

[0053] Step S2: Preprocess the graph data set: match the appropriate type label for each node in the BFDG (bidirectional function dependency graph) through regular matching; use Struc2Vec (graph embedding algorithm) to perform graph embedding training on the BFDG (bidirectional function dependency graph), and use the embedding result as the feature vector of the node. Construct an LDGCNN (link dynamic graph) model and train it through the input type label and feature vector. Traverse the BFDG (bidirectional function dependency graph) and use regular expressions to match different labels for different instruction types. For example, the regular expression of xor is <%ID>=xor.*, and the regular expression of GEP is <%ID>=getelementptr.*. At the same time, the BFDG (bidirectional function dependency graph) is trained through graph embedding using the DeepWalk method, and the numbers corresponding to the nodes in the BFDG (bidirectional function dependency graph) are determined through the string complete matching method, thereby determining the feature vectors of the nodes. The overall process is as follows: Figure 2 As shown in the figure, first read a BFDG (bidirectional function dependency graph) from the data set to obtain its node list, that is, the list of LLVM IR statements; then traverse the list, for each IR statement, determine its type label through regular matching, and store the number corresponding to its label in the node_tag list, and find the feature vector corresponding to the IR statement from the embedding result through the string complete matching method, and store it in node_feature; then number the nodes in the BFDG (bidirectional function dependency graph), represent the node content with its number, and represent the edge with an ordered pair of node numbers to generate a new graph; finally, store the original data.

[0054] The model used for parallel recognition of parallel code snippets is the linked dynamic graph convolutional neural network LDCGNN. The overall structure of the network is mainly a four-layer feature extraction layer, a fully connected layer, a maximum pooling layer, and finally an MLP (multi-layer perceptron) aggregation. The dimension of the node embedding vector is 1*200, and the node type label is 46. After four layers of feature extraction, the features learned in each layer are spliced ​​and input into a fully connected layer, and then the global features of the point cloud are obtained through maximum pooling, and spliced ​​with each layer of features obtained in the feature extraction part. The spliced ​​global features are aggregated through four layers of multi-layer perceptrons, and finally it is determined whether the code snippet can be parallelized. If it can be parallelized, it is 1, and if it cannot be parallelized, it is 0. The output dimensions of the graph convolution layer are 32, 32, 32, and 1 respectively. Then, after convolution, the dimension of the feature vector of each node is 1*97. Assuming that a graph has m nodes, the representation of the graph after convolution is an m*97 feature matrix, and each row represents the feature vector of a node. The loss function uses a bistable logic loss function.

[0055] Step S3: Calculate the complexity value for the code snippet.

[0056] This step proposes a set of metrics that measure various categories of software complexity to identify the most complex software units as prerequisites for refactoring. These metrics include program size, data structures, control flow, and data flow.

[0057] Program size (M1) refers to the sum of all operators (N1) and operands (N2) of a program. Operands usually represent data; operators are code elements that process or operate on operands and produce results:

[0058] M1=N1+N2

[0059] Control flow (M2): Determined by the number of branch statements (d) in the program:

[0060] M2=d+1

[0061] Data flow (M3): The input information flow (in) contains input variables, read access rights to external data structures, and return values ​​from the called program organization unit (POU). The output information flow (out) contains output variables, write access rights to external data structures, and variables passed to the called program organization unit (POU). The data flow (M3) is:

[0062] M3=in*out

[0063] Code type (M4): If the program contains a loop structure, M4 is assigned a value of 0.5, otherwise it is assigned a value of 0;

[0064] Finally, different weights are assigned to different complexity metrics. In this method, M4 is assigned a weight of 1 / 2, while M1, M2, and M3 are assigned a weight of 1 / 6 respectively. i Need to meet Finally, we get the complexity value C:

[0065]

[0066] Step S4: The IR code representations whose complexity values ​​exceed the set threshold are used to identify the parallelizable code fragments through the model. Finally, the header file and related variable definitions of the file are retained, and the identified parallelizable code fragments are split to obtain a parallelizable program.

[0067] Figure 3 The following is a comparison chart of the ST code before and after parallelization. Using the model trained through the above steps, the parallelizable part of the code is extracted. After extraction, the results obtained by this method are compared with the previous mainstream recognition methods, and the results are shown in Table 1:

[0068] Table 1

[0069]

[0070] Based on this result, it can be seen that the method proposed in this paper has good feasibility and effectiveness.

Claims

1. A PLC programming language program parallel detection method based on deep learning, characterized in that: The following steps are involved: Step S1: convert the PLC programming language into IR code representation, mark the IR code representation according to parallelization and non-parallelization, generate a bidirectional function dependency graph BFDG, and form a graph data set; Step S2: Obtain the matching type label of each node based on the graph dataset, build a parallel detection model based on the graph embedding algorithm Struc2Vec and the link dynamic graph LDGCNN model, and detect whether it is parallel; Step S3: Calculate the complexity value for the code snippet; Step S4: The IR code representation with a complexity value exceeding the set threshold is used to identify the code fragment through the trained LDGCNN model. If the recognition result is to be parallelized, the header file of the code fragment and the related variable definition are retained, and the code fragment is split to obtain a parallel program.

2. The method for parallel detection of PLC programming language programs based on deep learning according to claim 1 is characterized in that: The bidirectional function dependency graph BFDG is a graph structure representation that contains both program data flow information and control flow information, and each node represents an LLVM IR statement. Before forming the BFDG, the IR code representation is processed, and then the control dependency and data dependency between nodes are integrated to generate the BFDG represented by a directed multigraph.

3. The method for parallel detection of PLC programming language programs based on deep learning according to claim 2 is characterized in that: The specific process of generating the bidirectional function dependency graph BFDG is as follows: S1.

1. Initialize the graph structure: create a global root node and use it as the starting point. Other irrelevant identifiers are connected to the root node. S1.2, traverse each line of statement in the IR code representation: process according to the statement type and obtain nodes and edges; S1.3, Node Construction: The nodes in the bidirectional function dependency graph BFDG include: all nodes obtained by traversing the IR code representation, as well as function entry and exit nodes, each function entry and exit has a separate node; S1.4, construct edges, including control flow edges and data flow edges; S1.

5. Store the constructed nodes and edges in the format of [(node1,node2),statement], where node represents the node and statement represents the edge.

4. The method for parallel detection of PLC programming language programs based on deep learning according to claim 3 is characterized in that: The specific implementation process of step S1.4 is as follows: (1) Control flow edge: Function call: A function call generates an edge from the call point to the entry point of the called method; Return statement: A return statement generates an edge from the method exit to the caller; Branch instruction: Based on the conditional jump statement, an edge is established between the branch target basic blocks; (2) Data flow edge: Dependencies between identifiers: Add data flow edges between identifiers; Cross-function data dependency: For method calls or return values, if the method call involves parameter passing or return value passing, a data flow dependency edge is established.

5. The method for parallel detection of PLC programming language programs based on deep learning according to claim 4 is characterized in that: The specific implementation process of step 2 is as follows: Step S2.1: Preprocess the graph dataset to obtain the matching type label of each node, use the graph embedding algorithm Struc2Vec to perform graph embedding training on BFDG, and use the embedding result as the feature vector of the node; Step S2.2: Construct a linked dynamic graph LDGCNN model, combine the type label and the feature vector of the node to obtain a new feature graph, input it into the LDGCNN model for training, and output whether it is parallel.

6. The method for parallel detection of PLC programming language programs based on deep learning according to claim 5 is characterized in that: The preprocessing specifically includes: matching the type label for each node in the BFDG through regular matching.

7. The method for parallel detection of PLC programming language programs based on deep learning according to claim 6 is characterized in that: The implementation process of step S4 is: calculate from the program size, data flow, control flow, and code type respectively, and multiply them by the corresponding weights respectively, and finally accumulate to obtain the complexity value, as follows: Program size M1 refers to the sum of all operators N1 and operands N2 of a program: M1=N1+N2 The control flow M2 is determined by the number of branch statements d in the program: M2=d+1 Data flow M3: The input information flow in includes input variables, read access rights to external data structures, and return values ​​of the called program organization unit POU; the output information flow out includes output variables, write access rights to external data structures, and variables passed to the called program organization unit POU. The data flow M3 is: M3=in*out Code type M4: If the program contains a loop structure, M4 is assigned a value of 0.5, otherwise it is assigned a value of 0; Finally, we get the complexity value C: Among them, the weight w i satisfy

Images