Fuzzy test method and system for compilation semantic inconsistency defect of MMIR compiler

Abstract

The invention discloses a fuzzy test method and system for compilation semantic inconsistency defects of an MMIR compiler, and the method comprises the steps: S1, eliminating all potential undefined behavior operations in a test program of the MMIR compiler, and obtaining all defined behavior operations after risk elimination; s2, determining an optimal descent path of the defined behavior operation according to the defined behavior operation, and converting the defined behavior operation into an executable program of an MMIR compiler test program; and S3, executing the executable program of the test program of the MMIR compiler in the S2, and carrying out a differential test on whether the executable program is correctly compiled by the MMIR compiler or not.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software engineering and software testing, and in particular to a fuzzing method for detecting inconsistencies in compilation semantics in MLIR (Multi-Level Intermediate Representation) compilers. BACKGROUND

[0002] Multi-Level Intermediate Representation (MLIR) is a general-purpose, extensible intermediate representation. An MLIR program can be viewed as a collection of operations from multiple dialects. A dialect is a modular, extensible unit that defines operations, types, and attributes for a particular domain or level of code abstraction. An operation represents a specific task or behavior in a dialect and is the basic unit of computation or transformation, which takes a list of operands and attributes as input, performs a predefined computation or transformation, and produces one or more results as output. In order to compile an MLIR program into an executable program, each operation in the MLIR program must be transformed into a corresponding operation in a specific target dialect (e.g., the llvm dialect and the spirv dialect), which can often be directly converted into existing intermediate representations such as LLVM IR (the intermediate representation adopted by the LLVM compiler infrastructure) and SPIR-V (an intermediate representation for GPU computing), and further converted into an executable binary file, which is referred to as an executable dialect hereinafter. Through this transformation, an MLIR program completes the entire compilation process and obtains an executable binary file. To achieve this transformation, the MLIR compiler provides a series of downcasts. Specifically, a downcast is a program transformation that converts operations from one dialect to another, which usually transforms an MLIR program from a dialect representing a high-level abstraction representation to a dialect representing a low-level abstraction representation. For example, the downcast “-convert-arith-to-llvm” is used to convert arithmetic operations in the arith dialect to corresponding operations in the llvm dialect. In addition, the MLIR compiler provides optimization passes in addition to downcasts, which improve program performance, reduce resource consumption, or simplify program structure while maintaining the semantics of the MLIR program, thereby optimizing the MLIR program. Optimization passes can operate on various abstraction levels of MLIR, i.e., optimizing the MLIR program on dialects at different abstraction levels. For example, the optimization pass “-arith-unsigned-when-equivalent” can replace signed number operations in the arith dialect with equivalent unsigned number operations, thereby optimizing the MLIR program.

[0003] Defects in the MLIR compiler are mainly divided into two types: crash defects and compilation semantic inconsistency defects. Compilation semantic inconsistency defects refer to incorrect code optimizations performed by the compiler during compilation, resulting in semantic inconsistencies between the MLIR program before and after optimization. Specifically, the execution results of the MLIR program change before and after optimization. When compilation semantic inconsistency defects occur, the compiler does not issue warnings or crashes, making them difficult to detect during compilation and leading to erroneous behavior at execution, potentially causing serious failures in real-world applications. Generally, the detection of compilation semantic inconsistency defects relies on differential testing of the compiler, comparing the execution results of the same test program under different optimization options: if the execution results are the same, it indicates that the compiler performed correct code optimizations for the same program when specifying different optimizations; otherwise, it indicates that the compiler performed incorrect code optimizations, thus detecting a compilation semantic inconsistency defect. The detection of compilation semantic inconsistency defects depends on the stability of the test program's execution results; that is, the test program must not contain random factors or undefined behavior. Undefined behavior refers to harmful behaviors that are explicitly defined by the programming language specification and occur during code execution. The causes of undefined behavior in MLIR are complex and varied, including using uninitialized variables, accessing memory out of bounds, performing invalid type conversions, or violating dialect-specific constraints. Currently, because undefined behavior cannot be circumvented in the generated code, existing testing techniques cannot detect compilation semantic inconsistencies in MLIR compilers.

[0004] In recent years, researchers have proposed several testing techniques for MLIR compilers, such as MLIRSmith and MLIIRod. MLIRSmith was the first MLIR program generation tool for testing MLIR compilers. MLIRSmith first constructs a program template based on the MLIR syntax, then fills the template according to semantic rules to generate a semantically valid MLIR program. MLIRod, on the other hand, guides the entire fuzzing process through operation dependency coverage and uses four mutation rules designed for operation dependencies to generate new MLIR programs, thereby improving the effectiveness of MLIR compiler testing. While both MLIRSmith and MLIIRod can detect crash defects in MLIR compilers, they are limited by the possibility of generated test programs exhibiting undefined behavior and the inability to convert MLIR programs into executable forms. Therefore, neither technique can detect compilation semantic inconsistencies in MLIR compilers. The two techniques mentioned above have demonstrated that generating semantically valid MLIR programs is significantly effective in detecting crash defects in MLIR compilers.

[0005] However, the test programs generated by the above two testing techniques may exhibit undefined behavior, thus failing to detect compilation semantic inconsistencies in the MLIR compiler. Specifically, MLIR programs generated by these techniques are likely to exhibit undefined behavior, leading to unpredictable execution results and ultimately resulting in numerous false positives. Furthermore, these techniques do not include components for converting MLIR programs into executable forms; therefore, they cannot detect compilation semantic inconsistencies in the MLIR compiler by determining whether the MLIR program's execution results meet expectations.

[0006] In summary, the existing technology has the following drawbacks and shortcomings:

[0007] 1) Test programs generated by existing methods may exhibit undefined behavior, leading to unpredictable program execution results.

[0008] 2) Existing methods cannot convert MLIR programs into executable form and cannot detect compilation semantic inconsistencies in the MLIR compiler. Summary of the Invention

[0009] To address the problem that existing testing techniques cannot detect compilation semantic inconsistency defects in MLIR compilers, this invention proposes a fuzzy testing method for compilation semantic inconsistency defects in MLIR compilers. By combining MLIR program conversion rules and descent path optimization strategies, it achieves efficient conversion of MLIR programs into executable forms, thereby enabling the detection of compilation semantic inconsistency defects in MLIR compilers.

[0010] This invention is achieved using the following technical solution:

[0011] Firstly, this invention proposes a fuzz testing method for semantic inconsistency defects in MLIR compilers, comprising:

[0012] S1, perform the elimination of all potential undefined behavior operations in the MLIR compiler test program, and obtain all defined behavior operations after risk elimination;

[0013] S2, determine the optimal descent path of the defined behavior operation based on the defined behavior operation, and convert the defined behavior operation into an executable program of the MLIR compiler test program;

[0014] S3, execute the executable program of the MLIR compiler test program mentioned in S2, and perform a differential test to determine whether the executable program is correctly compiled by the MLIR compiler.

[0015] In some implementations, S1 further includes collecting operations from different dialects in the MLIR compiler test program, identifying all potential undefined behavior operations; when a potential undefined behavior is detected, generating a safe operand for the risky operation that caused the undefined behavior, replacing the original operand of the undefined behavior operation with it, and eliminating all potential undefined behavior operations in the MLIR compiler test program.

[0016] In some implementations, the determination of all potential undefined behavior operations follows four rules, namely undefined behavior caused by shape inconsistency, undefined behavior caused by index out of bounds, undefined behavior caused by erroneous memory operations or conflicting memory semantics, and undefined behavior caused by scalar computation.

[0017] In some implementations, S2 further includes constructing a descent path for the defined behavioral operations; associating all defined behavioral operations of the MLIR compiler test program at any time during the descent process with descent passes, and selecting the currently optimal descent pass to descent the program: the currently optimal descent pass refers to the descent pass that satisfies the preference to select the descent pass with the earlier partial order relation of the defined behavioral operations.

[0018] In some implementations, the step of associating all defined behavioral operations of the MLIR compiler test program at any time during the descent process with descent passes and selecting the currently optimal descent pass to descent the program is executed dynamically during the descent process. That is, for a given MLIR compiler test program, the descent pass topological sort is repeatedly performed and the descent pass is specified to descent the program until all operations in the program are converted into their corresponding representations in the executable dialect.

[0019] In some implementations, S3 further includes an operation-aware optimization pass recommendation strategy, which specifies different optimization passes associated with the defined behavioral program operations of the MLIR compiler test program during the descent process to construct program differences; then, it examines multiple execution results obtained by the same MLIR compiler test program through specifying different optimization passes, and if inconsistent execution results are found, it indicates that the MLIR compiler has incorrect compilation behavior, thereby detecting a compilation semantic inconsistency defect.

[0020] Secondly, this invention proposes a fuzz testing system for semantic inconsistency defects in MLIR compilers, comprising:

[0021] The module is used to eliminate all potential undefined behaviors in the MLIR compiler test program and obtain all defined behaviors after risk elimination.

[0022] The conversion module is used to determine the optimal descent path of the defined behavior operation based on the defined behavior operation, and convert the defined behavior operation into an executable program of the MLIR compiler test program;

[0023] The test module is used to execute the executable program of the MLIR compiler test program and perform differential tests to determine whether the executable program is correctly compiled by the MLIR compiler.

[0024] Compared with the prior art, the beneficial effects and advantages of the present invention are as follows:

[0025] 1) This invention ensures that the MLIR program can be compiled into an executable form through a descent path optimization strategy, while efficiently converting each operation in the MLIR program into its representation in the executable dialect, eliminating redundant steps in the descent process, thereby achieving optimization of the descent process;

[0026] 2) This invention utilizes an operation-aware optimization recommendation strategy designed in differential testing, which can effectively detect compilation semantic inconsistencies in the MLIR compiler. Attached Figure Description

[0027] Figure 1 This is the overall flowchart of the MLIR compiler semantic inconsistency defect fuzzing method of the present invention.

[0028] Figure 2 This is an example diagram of the MLIR compiler test program, where the affine.vector_load operation in the second line is an undefined behavior operation.

[0029] Figure 3 It is using the present invention to Figure 2 Example image showing the results of undefined behavior elimination performed by the MLIR program.

[0030] Figure 4 This is an example diagram of the descent path for the affine.for and scf.if operations.

[0031] Figure 5 This is a Venn diagram of the unique defects detected within 12 hours by the DESIL method proposed in this invention and the enhanced versions of the existing methods MLIRSmith and MLIRD.

[0032] Figure 6 This is a block diagram of the MLIR compiler semantic inconsistency defect fuzzing system of the present invention.

[0033] Figure 7 This is a diagram illustrating the implementation process of the MLIR compiler semantic inconsistency defect fuzzing test method and system of the present invention. Detailed Implementation

[0034] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0035] Example 1: As Figure 1 The diagram shown is an overall flowchart of the fuzzing method for compiling semantic inconsistency defects of the MLIR compiler of the present invention.

[0036] Step 1: Eliminate all potential undefined behaviors in the MLIR compiler test program to obtain all defined behaviors after risk elimination; wherein, the defined behaviors refer to safe operations that execute predefined behaviors. This step further includes the following processing:

[0037] Step 1.1: Collect operations from different dialects in the MLIR compiler test program to identify all potential undefined behavior operations in the MLIR compiler test program; undefined behavior operations refer to risky operations that may lead to undefined behavior. This step includes: receiving a given MLIR compiler test program and traversing it to collect all undefined behavior operations contained therein. An MLIR compiler test program corresponds to an operation sequence, where some operations include one or more nested regions (code blocks), and each nested region also includes an operation sequence. Thus, the entire MLIR compiler test program forms a recursive nested structure of "operation-nested region-operation," recursively traversing the operation sequences of each nested region in the MLIR program in a top-down manner, thereby identifying and collecting all undefined behavior operations in the MLIR compiler test program.

[0038] Specifically, identifying all potential undefined behaviors follows four rules:

[0039] The first type of undefined behavior is caused by shape inconsistency: This occurs when the shape or dimension of a vector (e.g., a matrix or tensor in deep learning dialects) is mismatched; for example, when using the `linalg.copy` operation to copy a vector, a source vector and a target vector with inconsistent shapes are specified. The second type of undefined behavior is caused by index out-of-bounds: This occurs when the MLIR compiler test program attempts to access a memory location outside the valid bounds. Causes include: 1) accessing a vector using an invalid index, such as using the `tensor.dim` operation to obtain the third dimension of a 2D vector; 2) performing a storage operation where the remaining space is less than the size of the target object, such as using the `affine.vector_store` operation to store a vector object into a memref object with less remaining space than the target object.

[0040] The third type of undefined behavior arises from erroneous memory operations or conflicting memory semantics within the program. These operations typically originate from the `memref` dialect. Causes include: conflicting memory semantics, such as a conflict between the alignment assertion specified in the `memref.assume_alignment` operation and the actual memory alignment; and erroneous memory operations, such as referencing invalid memory space after a `memref.realloc` operation has reallocated memory. The fourth type of undefined behavior is caused by scalar computation operations. Causes include shift overflows, signed integer overflows, and division by zero. For example, performing a division operation using the `arith.ceildivsi` operation might result in dividing by zero. Step 1.2: When the above rules detect potential undefined behavior at runtime, a safe operand is generated for the risky operation that might cause undefined behavior. This safe operand replaces the original operand of the undefined behavior operation. All potential undefined behavior operations in the MLIR compiler test program are eliminated. This step includes: at runtime, inserting detection operations into the MLIR compiler test program to detect whether an undefined behavior operation will cause undefined behavior; and inserting operand replacement logic for the undefined behavior operation into the MLIR compiler test program. For example... Figure 2 , Figure 3 As shown, in the case of eliminating instances of undefined behavior, Figure 2 In the MLIR compiler test program shown, on line 2, the affine.vector_load operation attempts to read a value of type vector<6xi32> starting from position %idx9 of the memory reference value %m (of type memref<14xi32>) and store it in the target vector %v. The above affine.vector_load operation will cause undefined behavior in the following two situations: (1) Invalid index of %idx9: If %idx9 exceeds the valid range of %m, undefined behavior will be caused. (2) Insufficient remaining space in %m: If the continuous remaining space in %m starting from %idx9 is smaller than the capacity of the target vector (%v), undefined behavior will also be caused. Figure 3The inserted red code eliminates the possibility of this operation causing these two undefined behaviors. Specifically, a runtime checker (part ①) is first inserted to check if there is enough free space for the memory reference %m. When insufficient space is detected, DESIL allocates and initializes a properly sized %new-m as a safe operand (part ②), otherwise the original %m is retained (lines 3-4). Finally (part ③), by replacing the operand %m with %m1 and ensuring the index of operand %idx9 is valid through modulo operation (%idx9 mod m1.dim(0)), all operands at risk of undefined behavior are replaced with safe operands, eliminating the possibility of the affine.vector_load operation causing undefined behavior during execution.

[0041] Step 2: Determine the optimal descent path for the defined behavioral operations based on the defined behavioral operations, and convert the defined behavioral operations into an executable program for the MLIR compiler test program; this step further includes the following processing:

[0042] Step 2.1: Construct operation-specific descent paths for the defined behavioral operations, including: establishing a mapping between each defined behavioral operation and a specified order of descent passes; and converting the corresponding defined behavioral operation into its corresponding representation in the executable dialect based on the descent pass sequence. The relevant documentation for the defined behavioral operations and descent passes is analyzed, and this descent pass sequence is referred to as an operation-specific descent path, using a triplet. Describe it. Among them... This indicates that the defined behavior operation will be performed. A set of descent passes required to convert to the corresponding representation in an executable dialect. for The set of partial order relations between any two descent passes in the set represents the partial order relation between the operations on the defined behavior. When performing a descent, the following conditions must be met: descent times Before descending Designated, in which , Let R represent any two distinct descent iterations selected from P. The partial order relation between all descent iterations in P is described in R. For example... Figure 4 In the example of descent path construction shown, the descent process from the affine.for operation to its corresponding representation in the executable dialect llvm, the llvm.cond_br operation, is as follows: In this example, the operation-specific descent path of the affine.for operation is... .

[0043] Step 2.2: For all defined behavioral operations of the MLIR compiler test program at any time during the descent process, perform descent pass associations, select the current optimal descent pass to descent the program, and further descent the MLIR compiler test program to obtain the topological sort of descent passes associated with all defined behavioral operations in the current MLIR program. The purpose of this step is to complete an effective descent process and avoid repeatedly applying the same descent pass. The current optimal descent pass refers to the descent pass that satisfies the rule in Step 2.1, that is, the descent pass that is selected first in the specified order of defined behavioral operations. Before descending Designated; specifically, assumed This represents the set of defined behavioral operations in the current MLIR procedure. Let represent the set of all associated descent passes. Since there are no cyclic dependencies among the descent passes, therefore for ( This means that any two distinct descent passes p1 and p2 are selected from the associated descent pass set P (where P represents the associated descent pass set), and if any one of them is a defined behavior operation... The descent path contains The partial order relation, which is in This also holds true. Therefore, a descent pass can always be obtained through topological sorting. Its satisfaction , (This indicates that there is no descent set P in the set of descent passes p) j Its partial order relation precedes p. i That is, p i The partial order relation precedes all other descents in the descent set P. It must be specified before all other descent passes, thus requiring the descent pass to be specified first in the MLIR compiler test program. To descend. Figure 4 In other words, when a program contains both affine.for and scf.if operations, the descent iteration will be specified first. This is the current optimal descent pass.

[0044] Of the two steps above, step 2.1 is a one-time task. After constructing the descent path specific to the operation, it can be directly reused in different MLIR compiler test programs during the compilation process. Step 2.1, on the other hand, is executed dynamically during the descent process. That is, for a given MLIR compiler test program, the descent pass topological sort is repeatedly executed, and the descent pass is specified to perform the descent, until all operations in the program are converted into their corresponding representations in the executable dialect.

[0045] Step 3: Execute the executable program of the MLIR compiler test program described in Step 2 to perform a differential test to determine whether the executable program is correctly compiled by the MLIR compiler. This step further includes executing an operation-aware optimization pass recommendation strategy. Based on the defined behavioral operations of the MLIR compiler test program during the descent process, different optimization passes related to these operations are specified to construct program differentials. Then, multiple execution results obtained by specifying different optimization passes for the same MLIR compiler test program are checked. If inconsistent execution results are found, it indicates that the MLIR compiler has incorrect compilation behavior, thereby detecting a compilation semantic inconsistency defect.

[0046] The operation-aware optimization recommendation strategy is combined with the descent path optimization process to construct test predictions for differential testing.

[0047] Simultaneously, the checksum of the MLIR compiler test program is calculated by summing the integer values ​​of all accessible defined behavioral operations (including the value of each element in the vector). Specifically, floating-point values ​​are not included in the checksum calculation because precision issues during the calculation may lead to false positives. Finally, the checksum is output at the end of the test program and compared in the differential tests as the execution result of the MLIR compiler test program.

[0048] Example 2: Figure 6 The diagram shows a block diagram of the fuzz testing system for compiler semantic inconsistency defects in the MLIR compiler of this invention. The system includes an acquisition module, a transformation module, and a differential testing module.

[0049] The module is used to eliminate all potential undefined behaviors in the MLIR compiler test program and obtain all defined behaviors after risk elimination.

[0050] The conversion module is used to determine the optimal descent path of the defined behavior operation based on the defined behavior operation, and convert the defined behavior operation into an executable program of the MLIR compiler test program;

[0051] The test module is used to execute the executable program of the MLIR compiler test program and perform differential tests to determine whether the executable program is correctly compiled by the MLIR compiler.

[0052] Table 1 shows detailed information on all defects detected by the method and system of this invention in the MLIR open-source project. This includes the submitted issue number, the component to which the defect root cause belongs, and the defect status. An asterisk (*) indicates that two bugs were reported together.

[0053] Table 1

[0054]

[0055] like Figure 5 The figure shows a comparison of the number of defects detected by the proposed method and system DESIL and enhanced versions of existing methods MLIRSmith and MLIRod within 12 hours. As mentioned above, DESIL is designed as a pluggable component, and therefore can be combined with any existing MLIR program generation tool. Figure 5 DESIL in (a) MLIRSmith and DESIL MLIRod These are DESIL fuzzing methods implemented using MLIRSmith and MLIRod as MLIR program generation tools, respectively. Furthermore, since MLIR programs generated by MLIRSmith and MLIRod may exhibit undefined behavior, and neither implements a descent component to convert the MLIR program into an executable form, therefore... Figure 5 It uses enhanced versions of MLIRSmith and MLIRD, namely MLIRSmith enhanced and MLIRod enhanced Compared to DESIL. Specifically, MLIRSmith enhanced and MLIRod enhanced By integrating with DESIL's descent path optimization and differential testing components, while maintaining their original program generation mechanisms, it follows DESIL's compilation process to generate executable programs for differential testing, thus possessing a certain ability to detect compilation semantic inconsistencies.

[0056] Figure 5 (b) DESIL MLIRSmith and MLIRSmith enhanced Comparing the number of defects detected within 12 hours, the former detected 13 unique defects (including 12 compilation semantic inconsistencies and 1 crash defect), while the latter only detected 4 unique defects (including 1 compilation semantic inconsistency and 3 crash defects). Similarly, in Figure 5 DESIL MLIRod and MLIRod enhanced In a comparison of the number of defects detected within 12 hours, the former detected 18 unique defects (including 16 compilation semantic inconsistencies and 2 crash defects), while the latter detected only 5 unique defects (all of which were crash defects). This result demonstrates the improvement of DESIL's defect detection capabilities compared to existing methods MLIRSmith and MLIRod.

[0057] In summary, this invention first designs a series of undefined behavior elimination rules to effectively prevent undefined behavior from being introduced by the MLIR compiler test program. Then, based on the MLIR documentation, a descent path optimization strategy is designed and implemented. Specifically, by adhering to the partial order relation of the dialect set in the program on the descent path, a topological sort is performed on the descent passes associated with all operations in the MLIR compiler test program. The descent passes are dynamically selected and specified to transform the MLIR compiler test program, and efficient transformation is achieved by exploring the optimal descent path during this process. Finally, to evaluate whether the test program is correctly compiled by the MLIR compiler, differential testing is used to detect compilation semantic inconsistencies in the MLIR compiler. Test predictions are constructed by comparing the checksums and outputs of the MLIR program and combining them with an operation-aware optimization pass recommendation strategy.

[0058] The preferred embodiments of the present invention have been described in detail above with reference to the accompanying drawings and technical solutions. These descriptions are merely preferred embodiments and are not intended to limit the scope or concept of the invention. To avoid unnecessary repetition, various possible combinations are not described separately. Any combination, modification, or improvement of the specific technical features described in the above embodiments, without contradiction, should fall within the scope of protection of this invention, provided it does not depart from the concept of the invention.

Claims

1. A fuzz testing method for semantic inconsistency defects in MLIR compilers, characterized in that, Bag include: S1, perform the elimination of all potential undefined behavior operations in the MLIR compiler test program, and obtain all defined behavior operations after risk elimination; S2, determine the optimal descent path of the defined behavior operation based on the defined behavior operation, and convert the defined behavior operation into an executable program of the MLIR compiler test program; S3, execute the executable program of the MLIR compiler test program mentioned in S2, and perform a differential test to determine whether the executable program is correctly compiled by the MLIR compiler.

2. The fuzzing method for semantic inconsistency defects in the MLIR compiler as described in claim 1, Its features are, S1 further includes collecting operations from different dialects in the MLIR compiler test program, identifying all potential undefined behavior operations; when a potential undefined behavior is detected, generating a safe operand for the risky operation that caused the undefined behavior, replacing the original operand of the undefined behavior operation with it, and eliminating all potential undefined behavior operations in the MLIR compiler test program.

3. The fuzzy testing method for semantic inconsistency defects in the MLIR compiler as described in claim 2, Its features are, The determination of all potential undefined behavior operations follows four rules, namely undefined behavior caused by shape inconsistency, undefined behavior caused by index out of bounds, undefined behavior caused by erroneous memory operations or conflicting memory semantics, and undefined behavior caused by scalar computation.

4. The fuzzy testing method for semantic inconsistency defects in the MLIR compiler as described in claim 1 Its features are, S2 further includes constructing a descent path for the defined behavioral operations; associating all defined behavioral operations of the MLIR compiler test program at any time during the descent process with descent passes, and selecting the current optimal descent pass to descent the program: the current optimal descent pass refers to the descent pass that satisfies the preference to select the descent pass with the earlier partial order relation of the defined behavioral operations.

5. The fuzz testing method for semantic inconsistency defects in the MLIR compiler as described in claim 4, Its features are, The step of associating all defined behavioral operations of the MLIR compiler test program at any time during the descent process with a descent pass and selecting the current optimal descent pass to descent the program is executed dynamically during the descent process. That is, for a given MLIR compiler test program, the descent pass topological sort is repeatedly executed, and the descent pass is specified to descent the program until all operations in the program are converted into their corresponding representations in the executable dialect.

6. The fuzzing method for semantic inconsistency defects in the MLIR compiler as described in claim 1, Its features are, The S3 further includes an operation-aware optimization pass recommendation strategy, which specifies different optimization passes associated with the defined behavioral operations of the MLIR compiler test program during the descent process to construct program differences. Then, examine the execution results of the same MLIR compiler test program obtained by specifying different optimization passes. If inconsistent execution results are found, it indicates that the MLIR compiler is exhibiting incorrect compilation behavior, thus detecting a compilation semantic inconsistency defect.

7. A fuzz testing system for semantic inconsistency defects in MLIR compiler compilation, characterized in that, Bag include: The module is used to eliminate all potential undefined behaviors in the MLIR compiler test program and obtain all defined behaviors after risk elimination. The conversion module is used to determine the optimal descent path of the defined behavior operation based on the defined behavior operation, and convert the defined behavior operation into an executable program of the MLIR compiler test program; The test module is used to execute the executable program of the MLIR compiler test program and perform differential tests to determine whether the executable program is correctly compiled by the MLIR compiler.

Images