MLIR compiler testing method based on dependency analysis

Abstract

The invention discloses an MMIR compiler testing method based on dependency analysis, which comprises the following steps of: initializing a seed pool to generate a to-be-tested MMIR program, and initializing operation dependency coverage of the to-be-tested MMIR program; randomly selecting a seed from the seed pool as a test program, and carrying out variation by randomly selecting one variation operator from the four variation operators; taking the varied test program as the input of an MLIR compiler, and randomly assigning a pass sequence to compile the program step by step so as to test the MLIR compiler; and analyzing the operation dependence coverage appearing in the test program, and if the test program enables the operation dependence coverage to be improved, adding the program for improving the operation dependence coverage into the seed pool so as to realize the MMIR compiler test. Compared with the prior art, the method has the advantages that the efficiency of coverage collection and program compiling of the compiler is improved, and the defects in the MMIR compiler can be effectively detected.

Description

Technical Field

[0001] The present invention relates to the fields of software engineering and software testing, and in particular to a testing method for a multi-level intermediate representation (MLIR) compiler. Background Art

[0002] MLIR (Multi-Level Intermediate Representation) is an innovative program intermediate representation introduced by LLVM, which aims to solve the problems of compiler development in specific fields.

[0003] As the infrastructure for compiler development, defects in the MLIR compiler may affect domain-specific compilers built on it. As a bridge between high-level and low-level languages, compilers play an important role in today's software ecosystem, and the harm of their defects has been confirmed in many studies. Therefore, it is crucial to ensure the quality of the MLIR compiler.

[0004] Due to the rich syntax and semantics of MLIR, as well as the language characteristics, existing compiler testing work cannot be used to test MLIR compilers. The existing MLIR compiler testing work MLIRSmith detects defects in the MLIR compiler infrastructure by randomly generating MLIR test programs. Specifically, MLIRSmith divides the random program generation process into two stages: 1) Test program template generation: MLIRSmith uses MLIR grammar to generate program templates to ensure that the final generated MLIR program conforms to the grammatical correctness of MLIR; 2) Test program instantiation: MLIRSmith fills in the MLIR program template generated in the first step according to the semantic constraints of MLIR to ensure that the generated MLIR program conforms to the semantic legality of MLIR.

[0005] Although MLIRSmith has improved the ability to detect MLIR compiler defects to a certain extent, it still has certain defects. Specifically, MLIRSmith uses a random strategy to generate MLIR test programs, which makes its exploration of the test input space inefficient and inadequate, thus limiting its defect detection capabilities. At the same time, MLIRSmith supports a limited number of dialects and operations, and supporting new dialects and operations requires a huge amount of work and is also very error-prone.

[0006] Therefore, the shortcomings of the existing technology include: 1) the existing method MLIRSmith generates test programs in a random manner, resulting in its exploration of the test input space being not efficient and sufficient, and 2) MLIRSmith supports a limited number of dialects and operations and is difficult to expand manually. Summary of the invention

[0007] In order to solve the problem of lack of guidance in the exploration of test input space faced by the existing MLIR compiler testing method MLIRSmith and to break through the technical limitations of the existing methods, the present invention proposes a MLIR compiler testing method based on dependency analysis, and for the first time proposes to analyze the program dependencies of the test program, and to guide the MLIR compiler testing method by collecting the patterns of program dependencies in the test program.

[0008] In order to achieve the above-mentioned invention object, the present invention is implemented by the following technical solutions:

[0009] The present invention proposes a MLIR compiler testing method based on dependency analysis, comprising:

[0010] The processing of the initialization phase is performed, including initializing the seed pool, generating the MLIR program to be tested, and initializing the operation dependency coverage of the MLIR program to be tested, so that the operation dependency coverage of the MLIR program to be tested in the seed pool satisfies the operation dependency coverage of the newly added MLIR program detected during the test; the operation dependency coverage is the ratio of the number of all operation dependency patterns participating in the test to the number of operation dependency patterns in all possible test program sets,

[0011] Execute the seed selection and mutation phase processing, including selecting a seed, i.e., a random MLIR program to be tested, from a seed pool, mutating the MLIR program to be tested, and using a mutation operator to modify the operation dependency in the test program to achieve the expected value of the operation dependency coverage, thereby obtaining a mutated test program;

[0012] Execute the processing of the compiler testing and seed storage phase, including using the mutated MLIR program to be tested obtained in the seed selection and mutation phase as the input of the MLIR compiler, using the MLIR program to be tested to compile a specified pass sequence, and performing MLIR compiler testing; evaluating the operation dependency coverage of the MLIR program to determine whether to add the new MLIR program to the seed pool and perform seed storage.

[0013] The operation dependency coverage of a given test case set T is expressed as:

[0014]

[0015] Among them, G t represents the operation dependency graph of MLIR program t, Indicates that in G t The program operation dependency pattern under all d-step reachability in , represents the set of all possible test programs, represents the set of operation dependency patterns corresponding to the operation dependency graph of all programs t under a given use case set T, The set of operation dependency patterns that represent the operation dependency graphs corresponding to all possible MLIR test programs t'.

[0016] Operation dependency coverage includes operation data dependency and operation control dependency, and the operation dependency pattern is a subgraph.

[0017] Use any of the four mutation operators to modify the operation dependencies in the test program. The four mutation operators include:

[0018] Add operation: add an operation instance to the operation dependency graph of the MLIR program, and build the operation control dependency and operation data dependency related to the instance;

[0019] Delete operation: Delete an operation instance in the operation dependency graph of the MLIR program, delete the data dependency and control dependency provided by the operation instance, and repair the data dependency destroyed by the delete operation;

[0020] Modify data dependency: modify the data dependency edges in the operation dependency graph of the MLIR program and keep the control dependency edges unchanged;

[0021] Modify control dependency: Modify the control dependency edge in the operation dependency graph of the MLIR program and keep the data dependency edge unchanged.

[0022] If the MLIR compiler crashes, a compiler defect is detected, and the necessary information to reproduce the defect is recorded, and the seed selection and mutation phase steps are returned; if no compiler defect occurs, a set of MLIR compilation test programs are obtained.

[0023] Compared with the prior art, the advantages and positive technical effects achieved by the present invention are as follows:

[0024] 1) Improves the efficiency of coverage collection and compiler compilation, and can effectively detect defects in the MLIR compiler;

[0025] 2) Improved testing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is an overall flow chart of the MLIR compiler testing method based on dependency analysis of the present invention;

[0027] Figure 2 It is an algorithm block diagram of the MLIR compiler testing method based on dependency analysis of the present invention;

[0028] Figure 3 This is an example diagram of an MLIR program;

[0029] Figure 4 yes Figure 3The operation dependency pattern diagram corresponding to the MLIR program;

[0030] Figure 5 yes Figure 3 Schematic diagram of the operation dependency pattern of the node "10:affine.store" under 1-step reachability;

[0031] Figure 6 Yes Figure 3 Schematic diagram of the operation dependency pattern after adding nodes and making mutations;

[0032] Figure 7 Yes and Figure 6 Schematic diagram of program modification corresponding to node addition mutation;

[0033] Figure 8 Yes Figure 3 Schematic diagram of the operation dependency pattern after node deletion mutation;

[0034] Fig. 9 Yes and Figure 8 Schematic diagram of program modification corresponding to node deletion mutation;

[0035] Fig.10 Yes Figure 3 Schematic diagram of the operation dependency pattern after data dependency modification and mutation;

[0036] Fig.11 Yes and Fig.10 Schematic diagram of program modification corresponding to data dependency modification mutation;

[0037] Fig.12 Yes Figure 3 Schematic diagram of the operation after the control dependency modification and mutation;

[0038] Fig.13 Yes and Fig.12 Schematic diagram of program modification corresponding to control dependency modification variation;

[0039] Fig.14 It is a line graph of unique defects detected by the dependency analysis-based MLIR compiler testing method (MLIRod) proposed in the present invention and the existing method (MLIRSmith) within 24 hours; wherein the horizontal axis represents the time used for testing, and the vertical axis represents the number of defects detected by the two methods at the corresponding time; the line with "o" represents the method MLIRod proposed in the present invention, and the line with "x" represents the existing method (MLIRSmith). DETAILED DESCRIPTION

[0040] The technical solution will be clearly described below in conjunction with the accompanying drawings and embodiments.

[0041] The execution process of the MLIR compiler testing method (MLIRod) based on dependency analysis of the present invention is mainly divided into three stages: an initialization stage, in which a seed pool and operation dependency coverage are initialized to accurately detect the growth of operation dependency coverage during the test process; a seed selection and mutation stage, in which a seed is randomly selected from the seed pool for mutation; a compiler testing and seed storage stage, in which the mutated seed is used as the input of the MLIR compiler, a random pass sequence is specified for MLIR compiler testing, and if a compiler defect is detected, the defect is recorded; finally, the mutated MLIR program and the MLIR program obtained by MLIRpass are evaluated.

[0042] like Figure 1 and Figure 2 As shown, the execution process of the MLIR compiler testing method (MLIRod) based on dependency analysis of the present invention is mainly divided into three stages:

[0043] (a) Initialization phase, the seed pool is initialized and the operation dependency coverage is initialized. For example, 50 seeds generated by MLIRSmith are used as the initial seeds, and the operation dependency coverage of these 50 seeds is used as the initial operation dependency coverage, so as to accurately detect the growth of the operation dependency coverage during the test process in subsequent tests. Generate a test program in the seed pool, and initialize the operation dependency coverage, the initialization specifically includes seed pool initialization and operation dependency coverage initialization; wherein, seed pool initialization is to select a suitable test program as the initial seed to complete; operation coverage initialization is to measure the operation dependency coverage that can be achieved by the MLIR program in the seed pool before the test begins, so as to ensure that the increase in operation dependency coverage detected during the test is accurate. The formal definition of operation dependency coverage initialization is as follows:

[0044] (1) MLIR program operation instance: An operation instance oi is represented by a triple:

[0045] (Oname, ODtypes, Rtypes); Oname represents the name of the operation, ODtypes represents the parameter type sequence of the operation, and Rtypes represents the return value type sequence of the operation. An operation instance represents an operation in an MLIR program.

[0046] (2) Operational data dependency: Let oi i Heoi j are two different operation instances in the MLIR program. If the operation instance oi i Defines a value and operates on the instance oi j If this value is used, the operation instance oi j Data depends on the operation instance oii .use To represent the operation instance oi j Data depends on the operation instance oi i .

[0047] (3) Operational control dependency: Let oi i Heoi j are two different operation instances in the MLIR program. If the operation instance oi j The execution of the operation depends on the operation instance oi i The result of the computation being executed is called the operation instance oi j Control depends on the operation instance oi i .use To represent the operation instance oi j Control depends on the operation instance oi i .

[0048] (4) Operation dependency graph: The operation dependency graph ODG is defined as a two-tuple G: G = (N, E); where N represents all nodes in the graph and E represents the edges in the graph. Each node in the graph represents an operation instance, and each edge in the graph is a control dependency or a data dependency. Figure 3 The following is an example of an MLIR program. The operation dependency diagram of the program example is as follows: Figure 4 As shown, each node represents an operation instance, the solid line edges represent the data dependency between operations, and the dotted line edges represent the control dependency between operations.

[0049] (5) d-step reachability: Given an operation dependency graph ODG = (N, E) and a node oi in the graph i ∈N, for any other node oi in the graph j ∈N. Node oi j From the node oi i d-step reachable if and only if there exists a node sequence <oi0,oi1,…,oi l >, where l≤d∧oi0=oi j ∧oi l =oi i ,and use to express this relationship. Figure 4 In the example, other nodes that have 1-step reachability to the "10:affine.store" node are: the "08:affine.for" node, the "09:arith.constant" node, and the "03:memref.alloc" node.

[0050] Represents a sequence of nodes <oi0,oi1,…,oi l > from the first node to the second to last node number, Represents a node sequence <oi0,oi1,…,oi l >, the operation data dependency edge from the kth node to the K+1th node, E represents the set of all edges in the operation dependency graph, Represents a node sequence <oi0,oi1,…,oi l >, the operation from the kth node to the K+1th node controls the dependency edge.

[0051] (6) Operation dependency pattern: Given an operation dependency graph G = (N, E), and a node oi i ∈N, its operation dependency pattern under d-step reachability is defined as a maximal subgraph G'=(N',E') of the operation dependency graph G. and like Figure 4 The operation dependency pattern corresponding to the MLIR program is shown in FIG. Figure 5 As shown in the figure, the nodes and edges marked with "o" are as follows Figure 3 The operation dependency pattern corresponding to the MLIR program of the node "10:affine.store" in the MLIR program example shown in the figure under 1-step reachability.

[0052] (7) Operation dependency coverage: It is defined as the ratio of the number of all operation dependency patterns involved in the test to the number of operation dependency patterns in all possible test program sets. The operation dependency coverage of a given test case set T is expressed as:

[0053]

[0054] Among them, G t represents the operation dependency graph of MLIR program t, Indicates that in G t The program operation dependency pattern under all d-step reachability in , represents the set of all possible test programs, ∪ represents the union, t∈T represents the program t in the given test case set T, Represents the set of all possible test programs The program t' in represents the set of operation dependency patterns corresponding to the operation dependency graph of all programs t under a given use case set T, represents the set of all possible test programs, The set of operation dependency patterns that represent the operation dependency graphs corresponding to all possible MLIR test programs t'.

[0055] In the actual test process, OD is given cov The exact number of denominators is not practical. The OD is obtained through the following two estimation processes: cov Denominator: 1) Generate a large number of MLIR programs and count the number of operation dependency patterns that appear in the program set. 2) Another estimation method is to continuously generate MLIR programs and continuously collect the operation dependency patterns that appear until the number of collected operation dependency patterns no longer increases or increases slowly.

[0056] MLIRod does not measure test adequacy through operation dependency coverage during the test process, but only guides the entire test process through operation dependency coverage. Therefore, in the actual test process, the MLIRod method of the present invention only collects OD cov The molecular part, that is, the number of operation dependency patterns involved in the test, guides the testing process according to the number of operation dependency patterns.

[0057] Through the above steps, all operation dependency coverage in the initial seed pool is collected as the initial operation dependency coverage for testing, which is used to accurately detect the increase in operation coverage during the test process.

[0058] (II) Seed selection and mutation stage, including the following processes:

[0059] A seed, i.e., a random MLIR program to be tested, is selected from the seed pool, and the MLIR program to be tested is mutated. Four mutation operators, including adding operations, deleting operations, modifying data dependencies, and modifying control dependencies, are used to modify the dependencies between operations in the test program, thereby achieving a higher expected value of operation dependency coverage. The relevant operators are described as follows:

[0060] (1) Adding an operation: Add an operation instance to the operation dependency graph of the MLIR program and build the operation control dependency and operation data dependency related to the instance.

[0061] For example, in Figure 4 Add a "++:arith.addf" node to the "06:arith.constant" node and "09:arith.constant" node to the "++:arith.addf" node, and construct a control dependency edge from the "08:affine.for" node to the "++:arith.addf" node. The modified operation dependency graph is as follows Figure 6 As shown in the figure, the added nodes and edges are marked with a broken line with an "x". The modification of the program by this mutation operator is reflected as follows: Figure 3Add an "arith.addf" operation between lines 9 and 10 of the program shown in the figure. This operation is under the "affine.for" operation in line 8 and takes the return values ​​of "arith.constant" in lines 6 and 9 as parameters. The modified program is as follows Figure 7 As shown, the added lines are marked by "++".

[0062] (2) Delete operation: Delete an operation instance in the operation dependency graph of the MLIR program, delete the data dependency and control dependency provided by the operation instance, and repair the data dependency damaged by the deletion operation. If the deleted node is a node that provides control dependency, all nodes that control dependency on the deleted node will be recursively deleted; if the deleted node provides data dependency, find other nodes with the same return value type as the deleted node to replace the deleted node to provide data dependency.

[0063] For example, in Figure 4 Delete the "09:arith.constant" node, and delete the control dependency edge from the "08:affine.for" node to it, as well as the data dependency edge from the "09:arith.constant" node to the "10:affine.store" node. To ensure the legality of the MLIR program after deleting the "09:arith.constant" node, MLIRod uses the "06:arith.constant" node with the same return value type as the "09:arith.constant" node, and constructs a data dependency edge from the "06:arith.constant" node to the "10:affine.store" node. The modified operation dependency graph is shown in the figure below: Figure 8 As shown in the figure, the deleted nodes and edges are marked with "o", and the added edges are marked with "x". The mutation operator modifies the program as follows: Figure 3 , and modify the first parameter of the "affine.store" operation in line 10 to "%f1". The modified program is as follows Fig. 9 As shown, the deleted lines are marked by "--" and the modified lines are marked by "~~".

[0064] (3) Modify data dependency: Modify the data dependency edges in the operation dependency graph of the MLIR program and keep the control dependency edges unchanged. In order to ensure the legality of the modified MLIR program, other nodes with the same return value as the node that originally provided the data dependency will be found to establish data dependency.

[0065] For example, in Figure 4Modify the data dependency of "10:affine.store" in the operation dependency diagram, and replace the data dependency from "09:arith.constant" node to "10:affine.store" node with the data dependency from "06:arith.constant" node to "10:affine.store" node with the same return type. Fig.10 As shown in the figure, the added data dependency is marked with an "x", and the deleted data dependency is marked with an "o". The modification of the program by the mutation operator is as follows: Figure 3 The first parameter of the "affine.store" operation in line 10 of the MLIR program shown is replaced with "%f1". The modified program is as follows Fig.11 As shown, the modified line is marked with "~~" and the modified part is marked with an "o" mark.

[0066] (4) Modify control dependency: Modify the control dependency edge in the operation dependency graph of the MLIR program and keep the data dependency edge unchanged. In order to avoid inserting new nodes during mutation, the mutation operator mainly considers moving a section of code outside the current code block. In order to ensure the legality of the MLIR program after mutation, the mutation operator will recursively analyze all operations under the same control block that its data depends on during the move operation, and move these operations uniformly outside the code block.

[0067] For example, in Figure 4 Modify the control dependency of the "10:affine.store" node. First, recursively solve the control dependency of the "08:affine.for" node and provide the data dependency node for the "10:affine.store" node, that is, Figure 4 Next, MLIRod will delete the control dependency of the "08:affine.for" node to the "10:affine.store" node and the "09:arith.constant" node. Finally, MLIRod will build the control dependency of the "07:affine.for" node to the "10:affine.store" node and the "09:arith.constant" node. The modified operation dependency diagram is as follows: Fig.12 As shown in the figure, the deleted dependency edges are marked with "o", and the added edges are marked with "x". The modification of the program by the mutation operator is as follows: Figure 3In the program shown, the "arith.constant" operation in lines 9 and 10, and the "affine.store" operation are moved forward to before the "affine.for" operation in line 8 according to the original order. The modified program is as follows Fig.13 As shown, deleted lines are marked by "--" and added lines are marked by "++".

[0068] (III) Compiler testing and seed storage phase: Use the mutated MLIR program to be tested obtained in the mutation phase to implement MLIR compiler testing, evaluate the operation dependency coverage of the MLIR program, and decide whether the program can be added to the seed pool. This phase further includes the compiler testing and seed storage steps, which are described as follows:

[0069] 3.1: Perform compiler testing. The mutated MLIR program to be tested obtained in the previous stage is used as the input of the MLIR compiler. The MLIR program to be tested is used to compile a specified pass sequence and perform MLIR compiler testing. The mutated MLIR program to be tested P is a randomly selected pass sequence of length L PassL = {pass1, pass2, ..., pass L}, use the mutated MLIR program to be tested to test the MLIR compiler in a step-by-step compilation manner. Specifically, split PassL to compile program P. For example, use program P as the input of the MLIR compiler, and get program P1 after pass1 compilation; then, use program P1 as the input of the MLIR compiler, and get program P2 after pass2 compilation, ..., until program P is used. L-1 As the input of the MLIR compiler, after passing L After compilation, we get program P L At this point, the entire compiler testing process ends. If the MLIR compiler crashes during this process, it is considered that a compiler defect has been detected and the defect is recorded.

[0070] 3.2: Perform seed storage and evaluate the operation dependency coverage of MLIR programs to determine whether to add new MLIR programs to the seed pool. Further, examine the operation dependency coverage of MLIR programs obtained through compilation. If the compiled MLIR programs improve the operation dependency coverage, then add these programs to the seed pool. Specifically, this step collects all the programs involved in the test, ProgL = {P, P1, ..., P L}, and examine whether these programs improve the operation dependency coverage; if there are programs that improve the operation dependency coverage, then add these programs to the seed pool. In this way, it is possible to generate dialects or operations that are not in the initial seed pool through the MLIR compiler pass, add these dialects and operations to the seed pool, and modify the program dependencies of these dialects and operations through the program mutation operator in stage 2 to achieve higher operation dependency coverage.

[0071] The present invention proposes a test guide based on MLIR program operation dependency, designs a set of mutation operators for operation dependency, and designs a complete MLIR compiler test method MLIRod based on the above core components. MLIRod uses the program's operation dependency coverage as a test guide to achieve an efficient MLIR compiler test process. At the same time, the MLIR test program is modified by mutations for operation dependency to achieve higher operation dependency coverage, so as to achieve efficient exploration of the compiler test input space, and finally achieve effective detection of MLIR compiler defects.

[0072] In summary, through the present invention, compiler testers can specify existing MLIR test programs as the initial seed pool during the test process to achieve more effective compiler testing and more effective exploration of the compiler input space. This helps to discover more compiler defects within the specified time. The following example will take the MLIR compiler as an example to implement the MLIR compiler testing method proposed in the present invention. In this example, the number of test programs in the initial seed pool is 50, the reachability parameter d used to collect operation dependency coverage is 2, and the specified pass sequence length L is 10.

[0073] like Fig.14 As shown, the number of defects detected by the proposed method MLIRod and the existing method MLIRSmith within 24 hours is compared. The comparison results show that the number of compiler defects detected by the proposed method MLIRod within 24 hours is increased by 121.43% compared with the existing method MLIRSmith.

[0074] As shown in Table 1, detailed information of unknown defects of MLIR compiler detected by the method MLIRod proposed in the present invention. Table 1 shows that the method proposed in the present invention has submitted 63 unknown defects to the MLIR project, of which 38 defects have been fixed and 48 defects have been confirmed by the MLIR compiler developers. This further demonstrates the defect detection capability of the method MLIRod proposed in the present invention. Among them, the MLIR compiler testing method (MLIRod) based on dependency analysis proposed in the present invention detects detailed information of all defects in the MLIR compiler open source project, including the submitted issue number and the root cause of the defect, and the root cause of the defect includes the pass type and defect status of the defect.

[0075] Table 1

[0076]

[0077] Therefore, the present invention proposes a new test guidance method, which uses the program dependency characteristics of the test program as a test guide. It can be implemented without the compiler to be tested being instrumented, which improves the efficiency of coverage collection and compiler compilation of the program, thereby improving the efficiency of the test, and can effectively detect defects in the MLIR compiler. A set of mutation operators for program dependencies is designed, and the grammatical and semantic legality of the program after mutation is ensured. The legal and effective program mutation guarantees the efficiency of the MLIR compiler test. A mechanism for adding the compiled MLIR program to the seed pool is designed, and the expansion of the dialects and operations that are not supported by the initial seed pool is realized in an efficient and lightweight method. Although the existing method MLIRSmith improves the effect of MLIR compiler testing to a certain extent, it is also limited by the problem of low efficiency of input space exploration caused by random exploration. In order to solve the limitations of the above-mentioned existing methods in testing MLIR compilers, the testing effect of MLIR compilers is further improved.

[0078] When the MLIR compiler (using pass) compiles the input MLIR program, it will get an output MLIR program. This output MLIR program may contain dialects that do not exist in the input program. By adding these MLIR programs compiled by the MLIR compiler that may contain dialects that the input MLIR program does not have to the seed pool, the dialects that are not originally in the seed pool can be expanded.

[0079] With this extension mechanism, the MLIR program tested contained a total of 430 operations and 20 dialects during the 24-hour test. If this mechanism is removed, it will only contain 256 operations and 13 dialects.

[0080] The above implementation steps are only used to help understand the specific methods and core ideas of the present invention, but do not limit the present invention in any way. Any changes and technical substitutions made by those skilled in the art in accordance with the protection scope of this application and the teachings and inspirations of the inventive concept without departing from the spirit of the present invention and without making creative work, all fall within the protection scope of the present invention.

Claims

1. A MLIR compiler testing method based on dependency analysis, characterized in that: include: The processing of the initialization phase is performed, including initializing the seed pool, generating the MLIR program to be tested, and initializing the operation dependency coverage of the MLIR program to be tested, so that the operation dependency coverage of the MLIR program to be tested in the seed pool satisfies the operation dependency coverage of the newly added MLIR program detected during the test; the operation dependency coverage is the ratio of the number of all operation dependency patterns participating in the test to the number of operation dependency patterns in all possible test program sets, Execute the seed selection and mutation phase, including selecting a seed, i.e., a random MLIR program to be tested, from a seed pool, mutating the MLIR program to be tested, modifying the operation dependency in the test program, achieving the expected value of the operation dependency coverage, and thus obtaining the mutated test program; Execute the processing of the compiler testing and seed storage phase, including using the mutated MLIR program to be tested obtained in the seed selection and mutation phase as the input of the MLIR compiler, using the MLIR program to be tested to compile a specified pass sequence, and performing MLIR compiler testing; evaluating the operation dependency coverage of the MLIR program to determine whether to add the new MLIR program to the seed pool and perform seed storage.

2. The MLIR compiler testing method based on dependency analysis according to claim 1, characterized in that: The operation dependency coverage of a given test case set T is expressed as: Among them, G t represents the operation dependency graph of MLIR program t, Indicates that in G t The program operation dependency pattern under all d-step reachability in , represents the set of all possible test programs, represents the set of operation dependency patterns corresponding to the operation dependency graph of all programs t under a given use case set T, The set of operation dependency patterns that represent the operation dependency graphs corresponding to all possible MLIR test programs t'.

3. The MLIR compiler testing method based on dependency analysis according to claim 1, characterized in that: The operation dependency coverage includes operation data dependency and operation control dependency, and the operation dependency pattern is a subgraph.

4. The MLIR compiler testing method based on dependency analysis according to claim 1, characterized in that: Use any of the four mutation operators to modify the operation dependencies in the test program. The four mutation operators include: Add operation: add an operation instance to the operation dependency graph of the MLIR program, and build the operation control dependency and operation data dependency related to the instance; Delete operation: Delete an operation instance in the operation dependency graph of the MLIR program, delete the data dependency and control dependency provided by the operation instance, and repair the data dependency destroyed by the delete operation; Modify data dependency: modify the data dependency edges in the operation dependency graph of the MLIR program and keep the control dependency edges unchanged; Modify control dependency: Modify the control dependency edge in the operation dependency graph of the MLIR program and keep the data dependency edge unchanged.

5. The MLIR compiler testing method based on dependency analysis according to claim 1, characterized in that: If the MLIR compiler crashes, a compiler defect is detected, and the necessary information to reproduce the defect is recorded, and the seed selection and mutation phase steps are returned; if no compiler defect occurs, a set of MLIR compilation test programs are obtained.

Images