Test case migration system and method for deep learning compiler
By extracting the operator instances from the deep learning library and combining the diversity sorting strategy, test cases are migrated to the deep learning compiler model loading stage, the problem of insufficient testing coverage in the model loading stage in the existing technology is solved, and efficient defect detection is achieved.
Patent Information
- Application Number
- CN202510373684.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-27
- Publication Date
- 2025-06-17
Smart Images
Figure CN120162271A_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of deep learning compiler testing, and specifically relates to a method for testing knowledge transfer of deep learning libraries and combining a diversity sorting strategy. Background Art
[0002] The related technologies of the present invention include:
[0003] (I) Deep learning compiler
[0004] The compilation process of a deep learning compiler can be divided into three main stages. ① In the model loading stage, the compiler takes the model constructed by different deep learning libraries (such as DL knowledge bases like PyTorch and tensorflow) as input and converts it into a unified high-level intermediate representation (IR). The deep learning model to be compiled is usually a directed acyclic graph, where nodes represent operators (i.e., tensor calculation functions) and edges represent data flows. Through the graph-level IR, the model differences between different libraries are hidden, simplifying the optimization and execution processes. Each operator is converted into a semantically equivalent IR expression during compilation. ② Then, hardware-independent optimization is performed on the graph-level IR to further reduce redundancy and improve efficiency. ③ Finally, in the low-level IR optimization stage, the high-level IR is converted into hardware-specific low-level IR to generate executable code for the target hardware.
[0005] (II) Test case migration
[0006] Test case migration refers to adjusting and migrating existing test cases to different software versions or platforms to adapt to new environments or requirements. According to the migration source of the test cases, the migration solutions include cross-version test case migration and cross-project test case migration. For example, migrating the test cases of OpenJDK 7 to test the OpenJDK 8 system belongs to cross-version migration. Since the test cases of the old version may not be directly usable, developers need to update the input data, expected results, and operation steps. On the other hand, migrating the test cases in OpenJDK to test the Oracle JDK program belongs to cross-project test case migration. Automated migration tools can identify the differences between the source version and the target version, reduce the workload of manual adjustment, and ensure the effectiveness and coverage of the test cases.
[0007] (III) Test case sorting
[0008] Test case sorting is a technique for optimizing the test execution order, aiming to improve the defect discovery efficiency. As the software system version iterates, the number of test cases gradually increases, and the test time and resource consumption also rise accordingly. By sorting the test cases, the cases most likely to discover defects can be executed first, thus discovering problems earlier and optimizing resource usage. For example, in a continuous integration environment, developers can determine the execution order of test cases based on historical defect data or risk assessment to ensure that defects are exposed as early as possible, detect more defects with limited resources, and repair the defects in a timely manner.
[0009] Existing deep learning compiler testing techniques mainly focus on the optimization phase while ignoring the model loading phase. Although tools like NNSmith can generate complex models to test the optimization phase, they cannot effectively cover the test requirements of the model loading phase. The model loading phase requires testing the diverse usage of each operator rather than the complex dependencies between operators. In addition, NNSmith only supports the ONNX library and a limited number of operators, restricting its practicality in testing the model loading phase. Therefore, there are obvious deficiencies in the test coverage of the current technology in the model loading phase. Intuitively, manually developing a test generation tool that follows the corresponding syntax may meet the test requirements of the model loading phase. However, this method may be both laborious and error-prone because of the large number of DL libraries and the operators they support. In addition, operators usually involve a large number of parameters, resulting in complex constraint conditions, further increasing the difficulty of developing such tools. Therefore, there is an urgent need for a lightweight alternative method to solve this challenging task. Summary of the Invention
[0010] The present invention aims to solve the problem of defect detection in the model loading phase of deep learning compilers, and proposes a test case migration system and method for deep learning compilers, obtaining the migrated test cases from the test cases of deep learning libraries to deep learning compilers, and further realizing the migration of efficient test cases for the model loading phase of deep learning compilers by combining a diversity-guided sorting strategy.
[0011] To achieve the above invention objectives, the present invention proposes the following technical solutions:
[0012] In a first aspect, the present invention proposes a test case migration system for a deep learning compiler. The system includes a test case migration module, a test case sorting module, and a test oracle module. Among them, the test case migration module is responsible for migrating knowledge by extracting operator instances from deep learning library tests, so as to create a set of migrated test cases for the model loading stage of the deep learning compiler; the test case sorting module is responsible for sorting the migrated test cases according to the diversity of the tests; the test oracle module is responsible for combining two types of test oracles to determine whether the migrated tests detect defects in the model loading stage of the deep learning compiler.
[0013] In a second aspect, the present invention proposes a test case migration method for a deep learning compiler implemented based on a test case migration system for a deep learning compiler, including:
[0014] Step 1, execute the test case migration module, and migrate knowledge by extracting operator instances from deep learning library (DL library) tests, so as to create a set of migrated test cases for the model loading stage of the deep learning compiler;
[0015] Step 2, execute the test case sorting module, and sort the migrated test cases according to the diversity of the tests;
[0016] Step 3, execute the test oracle module, and combine two types of test oracles to determine whether the set of migrated test cases detects defects in the DL compiler model loading stage.
[0017] In some embodiments, step 1 further includes:
[0018] 1.1, select the official test cases of the integrated deep learning library and the test cases generated by the fuzz testing tool as the migration source;
[0019] 1.2, select DocTer and DeepREL as the test tools to generate test cases.
[0020] In some embodiments, step 2 further includes:
[0021] 2.1, sort the set of migrated test cases according to the operator signature diversity, and further include:
[0022] Determine the order of test cases with different operator signatures according to the following intuitions: Intuition 1, in deep learning library tests, the larger the number of tests with a certain operator signature, it indicates that this operator may receive more attention due to its complex implementation logic, more boundary cases, etc.; Intuition 2, in the test suite equipped with the deep learning compiler, the smaller the number of test cases with a certain operator signature, it indicates that DL compiler developers still pay little attention to the test of the conversion of this operator instance;
[0023] Based on the above Intuition 1 and Intuition 2, calculate the priority score of operator OPi through the ratio of Num_DLL_OPi to Num_DLC_OPi, and sort the migrated test case set according to the priority of operator OPi.
[0024] In some embodiments, step 2 further includes:
[0025] 2.2. Sort the migrated test case set according to the diversity of the parameter space: divide the value space of each operator instance parameter into a series of subspaces, and each subspace aggregates specific values with potentially similar test capabilities; specifically, for the parameter value space being an integer range, divide it into five subspaces (-∞, -2], [-1], [0], [1], and [2, ∞); for the parameter value space being a floating-point value range, divide it into three subspaces (-∞, 0), [0], and (0, ∞); for the parameter value space being a composite type of tensors, first consider each tensor type value as a unique subspace according to the finite tensor type parameter value space, then divide the parameter value space of the tensor shape, and use the integer space division method to divide the value space of the dimension attribute into seven subspaces [0], [1], [2], [3], [4], [5], and [6, ∞), and finally perform an intersection operation through each subspace to form the final subspace set of the tensors;
[0026] For an operator signature, based on the subspaces of the divided parameter value space, measure the parameter setting diversity score of the operator instance and the parameter setting diversity score of the operator instance with the determined priority, and measure the percentage of the new subspaces or paired subspaces covered by each operator instance parameter or paired parameter combination compared to the set of operator instances with the determined priority, so as to sort the migrated test case set.
[0027] In some embodiments, step 2 further includes:
[0028] 2.3. Design a global optimization sorting strategy, and preferentially sort the test cases according to the product of the operator signature diversity score and the parameter setting diversity score (i.e., the operator instance diversity); after adding the test case with the maximum operator instance diversity to the preferred result, update the parameter setting diversity of the remaining test cases with the same operator signature for subsequent iterations.
[0029] In some embodiments, the two test oracles in step 3, namely crash and inference consistency, include:
[0030] Taking the crash as the test oracle, there is: after filtering out invalid test cases, monitor the abnormal termination of the compiler during the DL model loading phase;
[0031] Taking the inference consistency as the test oracle, we have: By comparing the output differences between the original model and the compiled model, conversion errors are determined based on the Chebyshev distance.
[0032] In some embodiments, the migrated test case is a single-layer DL model converted from an operator instance, and its core semantics lie in (1) the signature of the operator and (2) the settings of each parameter in the operator instance.
[0033] In some embodiments, if the parameter value space is a finite set of specific values, each unique specific value in the parameter value space is regarded as a unique subspace, representing the unique configuration of using the operator instance.
[0034] Based on the prior art, the present invention can achieve the following beneficial technical effects:
[0035] 1) The selected migration sources cover the diversity of human experience and automated exploration, while the tests generated by the tool help to explore the boundaries, laying a good foundation for the migration method;
[0036] 2) Sort the migrated test cases according to the diversity of the tests, and design a global optimization sorting strategy to overcome the disadvantage that due to the large number of migrated tests during the execution process and the evolution of the deep learning library (DL library) and the compiler, test case migration and execution need to be performed frequently, which can improve the test efficiency;
[0037] 3) Combine two test oracles to determine whether the migrated test case set detects defects in the DL compiler model loading stage, providing a correctness verification guarantee for the test case migration behavior for the deep learning compiler. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 It is a module diagram of a test case migration system for a deep learning compiler according to the present invention;
[0039] Figure 2 It is an overall flowchart of a test case migration method for a deep learning compiler according to the present invention;
[0040] Figure 3 It is a schematic diagram of the specific implementation process of a test case migration method for a deep learning compiler according to the present invention;
[0041] Figure 4 It is a template example diagram for encapsulating a PyTorch operator instance into a single-layer operator DL model. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0042] The present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely used to explain the present invention and are not intended to limit the present invention.
[0043] As Figure 1 shown, a test case migration system for a deep learning compiler (abbreviated as OPERA) according to the present invention includes a test case migration module, a test case sorting module, and a test oracle module. Among them, the test case migration module and the test case sorting module are two important modules.
[0044] Among them, the test case migration module is responsible for migrating knowledge by extracting operator instances from deep learning library (DL library) tests, so as to create a set of migrated test cases for the model loading stage of the deep learning compiler (DL compiler); the test case sorting module is responsible for sorting the migrated test cases according to the diversity of the tests. The test oracle module is responsible for combining two types of test oracles to determine whether the migrated tests detect defects in the model loading stage of the DL compiler.
[0045] As Figure 2 shown, a test case migration method for a deep learning compiler according to the present invention, the overall process includes the following steps:
[0046] Step 1: Execute the test case migration module, extract operator instances from deep learning library (DL library) tests as migration knowledge, and generate a single-layer model through template encapsulation, so as to create a set of migrated test cases for the model loading stage of the deep learning compiler (DL compiler); this step is specifically described as follows:
[0047] 1.1. Select the official test cases of the integrated deep learning library (such as PyTorch, Keras, ONNX) and the test cases generated by fuzz testing tools (such as DocTer, DeepREL) as the migration source; the selected migration source covers the diversity of manual experience and automated exploration. Manually written tests require professional knowledge to consider various usages of operators under constraint conditions, while tests generated by tools help to explore source code boundary case situations. There are already various test tools for deep learning libraries in the literature. The present invention selects DocTer and DeepREL as test tools. DocTer extracts API constraints from official documents to generate tests, and DeepREL automatically infers API relationships based on the syntax and semantic information of the API and generates tests to generate test cases;
[0048] 1.2. Extract operator instances from the DL library test cases (such as Figure 3torch.nn.Conv2d(in_channels=3, out_channels=3, kernel_size=1) in it, and convert it into a single-layer DL model. Specifically, record the operator signature and its parameter values through the instrumentation API, extract the operator instance, and encapsulate it into a single-layer DL model using a template for testing; as Figure 4 shown, a template for encapsulating a PyTorch operator instance into a single-layer operator DL model. A single-layer operator model refers to a DL model that contains only a single network layer / operator. And use these migrated DL models as the input of the DL compiler, as the migrated test cases, for compiler testing; although these sources provide a large number of test cases, due to different input formats, most of the deep learning library test cases cannot be directly used for compiler testing. The DL compiler usually accepts DL model input, while the test cases of the library mostly exist in the form of Python code and lack a complete model structure. Therefore, it is necessary to extract DL models from the DL library test cases for compiler testing. For this purpose, operator instances are used to make up for this gap. An operator instance refers to the usage of an operator with specific parameter settings, such as Figure 3 shown. Further, the single-layer DL model loading stage mainly involves converting each operator instance of the DL model into an intermediate representation (IR), that is, single-operator equivalent conversion, which is suitable for creating a single-layer DL model and subsequent defect localization; each DL library has a customized model generation template to adapt to different model construction methods;
[0049] Specifically, test cases with different operator signatures mean that the corresponding test cases have different semantics.
[0050] A migrated test case is a single-layer DL model converted from an operator instance, and its core semantics lie in (1) the signature of the operator and (2) the setting of each parameter in the operator instance;
[0051] Step 2, execute the test case sorting module to sort the migrated test cases according to the diversity of the tests; the specific description of this step is as follows:
[0052] According to the characteristics of the application scenario, design a test case sorting strategy based on diversity, which sorts the set of migrated test cases according to the diversity of information in these two dimensions:
[0053] 2.1. Sort the set of migrated test cases according to the operator signature diversity, and this process includes the following processing:
[0054] Determine the order of test cases with different operator signatures based on the following intuitions: Intuition 1, in the testing of deep learning libraries (DL libraries), a larger number of tests with a certain operator signature indicates that this operator may receive more attention due to its complex implementation logic, more boundary cases, etc.; Intuition 2, in the test suite equipped with the DL compiler (i.e., a specific test suite for the model loading phase), a smaller number of test cases with a certain operator signature indicates that DL compiler developers still pay little attention to the testing of the instance conversion of this operator. Therefore, if an operator OPi appears more frequently in the migration test set of the DL library (the number of occurrences is denoted as Num_DLL_OPi), and less frequently in the test suite equipped with the DL compiler (the number of occurrences is denoted as Num_DLC_OPi), then a higher priority score is assigned to it. Based on these intuitions, the priority score of operator OPi is calculated by the ratio of Num_DLL_OPi to Num_DLC_OPi, and the sorted test case set after migration is sorted according to the priority of operator OPi.
[0055] 2.2. Sort the migrated test case set according to the diversity of the parameter space, and this process includes the following processing:
[0056] Divide the value space of the parameters of each operator instance into a series of subspaces, and each subspace aggregates specific values with potentially similar test capabilities. If the parameter value space is a finite set of specific values, each unique specific value in the parameter value space is regarded as a unique subspace, representing the unique configuration of using this operator instance. Specifically, ① if the parameter value space is an integer range, pay more attention to some special values in the DL library, such as -1, -0, and 1, and divide it into five subspaces (-∞, -2], [-1], [0], [1], and [2, ∞). ② For the parameter value space that is a floating-point value range, divide it into three subspaces (-∞, 0), [0], and (0, ∞). ③ For the composite type of the parameter value space that is a tensor (with some typical attributes, such as tensor type and shape), first regard each tensor type value as a unique subspace according to the finite tensor type parameter value space, and then divide the parameter value space of the tensor shape (which belongs to the list type), and the values in the list are integers, so the integer space division method is adopted. The size of the list refers to the dimension of the tensor, and considering some special values, the value space of the dimension attribute is divided into seven subspaces [0], [1], [2], [3], [4], [5], and [6, ∞), and finally the intersection operation is performed through the subspaces of each attribute to form the final set of subspaces of the tensor.
[0057] For an operator signature, based on a subspace of the partitioned parameter value space, measure the diversity score of the parameter settings of an operator instance against the diversity score of the parameter settings of the operator instances with determined priorities. Specifically, for an operator instance, measure the percentage of new subspaces or paired subspaces covered by its parameters or paired parameter combinations compared to the set of operator instances with determined priorities. This method draws on the idea of combinatorial testing.
[0058] 2.3. Design a global optimization sorting strategy to sort the migrated test case set. This process includes the following handling:
[0059] Prioritize test cases according to the product of the operator signature diversity score and the parameter setting diversity score (i.e., operator instance diversity); after adding the test case with the maximum operator instance diversity to the priority result, update the parameter setting diversity of the remaining test cases with the same operator signature for subsequent iterations. The prioritization process here is based on the heap sort algorithm because of its high efficiency (time complexity O(nlogn), space complexity O(1)).
[0060] 3. Execute the test oracle module and combine two test oracles to determine whether the migrated test case set detects defects in the DL compiler model loading phase. This step is specifically described as follows:
[0061] To verify whether a test case can detect a defect, two test oracles, namely crash and inference consistency, are used. Taking the crash as the test oracle, there is: after filtering invalid test cases, monitor the abnormal termination (such as segmentation fault) of the compiler during the DL model loading phase. Taking the inference consistency as the test oracle, there is: compare the output differences between the original model and the compiled model, and determine conversion errors based on the Chebyshev distance (threshold 1e-3). Given a random model input, a difference in the confidence of the inference results given by the DL models before and after compilation greater than the threshold will be considered to have detected a defect.
[0062] 3.1. Test oracle experiment settings are specifically described as follows:
[0063] Objects under test: Three widely used deep learning compilers, TVM, TensorRT, and OpenVINO, were studied, and their latest versions (TVM v0.13, TensorRT v8.6, OpenVINO v2023.1.0) were selected to better detect unknown defects. These compilers contain multiple front-ends for converting models from different deep learning libraries into high-level intermediate representations. The evaluation focused on the PyTorch, Keras, and ONNX front-ends, which handle models from the PyTorch, Keras, and ONNX libraries respectively. Additionally, since TensorRT does not support the Keras front-end, the evaluation covered eight front-ends of the three compilers in total.
[0064] Baseline methods: By comparing OPERA with NNSmith and COMET, the effectiveness of the transfer-based approach was evaluated. NNSmith and COMET generate multi-operator deep learning models for testing, which are convenient for comparison with OPERA's single-operator models. NNSmith is a state-of-the-art deep learning compiler testing technology that supports 75 operators of the ONNX library and randomly generates models. COMET generates diverse models through a mutation operator and a coverage search algorithm. To evaluate OPERA's test case sorting strategy, this patent compared several mainstream sorting algorithms: Random strategy (Random): Randomly sort the tests. FAST: Treat the tests as strings and accelerate the search for diverse tests through data mining algorithms. Total coverage first (Total): Sort by the number of statements covered. Additional coverage first (Additional): Sort by the number of new statements covered.
[0065] 3.2. Experimental results are described as follows:
[0066] To verify the defect detection ability of OPERA, NNSmith and COMET were selected as baseline methods, and their fault-finding capabilities were compared within the same time. Table 1 shows the number of defects detected by OPERA, presenting the number of defects detected by OPERA in 8 different front-ends. Specifically, OPERA detected 79, 43, and 48 defects in TVM, TensorRT, and OpenVINO respectively, significantly outperforming NNSmith (11, 2, 5) and COMET (6, 0, 4). The unique defects detected by NNSmith and COMET mainly concentrated in the optimization stage, while OPERA detected 164 unique defects, among which 156 defects were located in the model loading stage. The experimental results show that OPERA has a significant advantage in the model loading stage test and is complementary to NNSmith and COMET. The advantage of OPERA lies in that it efficiently covers 477 operators through lightweight migration technology, far higher than NNSmith (75) and COMET (72), verifying the positive correlation between operator coverage and defect detection.
[0067] To verify the effectiveness of the OPERA sorting algorithm, four of the most mainstream sorting algorithms were selected as baseline methods, and their efficiencies in detecting defects on different front-ends were compared, with APFD used as the evaluation criterion. Table 2 shows the comparison results of different sorting strategies regarding the APFD value.
[0068] As can be seen from the table, among all the test case sorting strategies, OPERA performed best on the eight test objects. On these eight test objects, the average APFD value of OPERA was 0.898, which was increased by 13.1%, 11.9%, 47.4%, and 37.2% respectively compared with the random-order OPERA, FAST, the test case sorting strategy based on total coverage, and the test case sorting strategy based on additional coverage. These results prove the effectiveness of the test case sorting strategy designed in OPERA. This also indicates that the test case sorting strategy designed for this migration scenario is more effective than the general white-box or black-box strategies.
[0069] Table 1
[0070]
[0071] Table 2
[0072]
[0073]
[0074] In summary, considering cost factors, the practical feasibility of this migration-based idea may still be hindered. Therefore, test case ranking is incorporated into the process of the present invention to discover more defects within a given test time budget, which helps to study the effect of this migration-based idea on efficiency improvement. In the face of the diversity of operator signatures, test cases with the same operator signature have the same priority. Therefore, how to further determine their priority becomes another challenge. This problem is solved by measuring the diversity of parameter settings for each operator instance. Inspired by the equivalence class partitioning theory, different considerations are made according to different types of operator instance parameters.
[0075] It should be noted that the above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, various changes and modifications can be made to the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.
Claims
1. A test case migration system for deep learning compilers, characterized in that: The system includes a test case migration module, a test case sorting module and a test prediction module, wherein the test case migration module is responsible for migrating knowledge by extracting operator instances from deep learning library tests, thereby creating a migrated test case set for the deep learning compiler model loading phase; the test case sorting module is responsible for sorting the migrated test cases according to the diversity of the tests; and the test prediction module is responsible for combining the two test predictions to determine whether the migrated tests have detected defects in the deep learning compiler model loading phase.
2. A test case migration method for a deep learning compiler implemented based on a test case migration system for a deep learning compiler as claimed in claim 1, characterized in that: The method includes: Step 1: Execute the test case migration module to migrate knowledge by extracting operator instances from the deep learning library test, thereby creating a migrated test case set for the deep learning compiler model loading phase; Step 2: Execute the test case sorting module to sort the migrated test cases according to the diversity of the tests; Step 3: Execute the test oracle module and combine the two test oracles to determine whether the migrated test case set detects defects in the DL compiler model loading phase.
3. A test case migration method for a deep learning compiler according to claim 2, characterized in that: The step 1 further comprises: 1.
1. Select the official test cases of the integrated deep learning library and the test cases generated by the fuzz testing tool as the migration source; 1.
2. Select DocTer and DeepREL as testing tools to generate test cases.
4. A test case migration method for a deep learning compiler according to claim 2, characterized in that: The step 2 further comprises: 2.
1. Sorting the migrated test case set according to operator signature diversity, further including: The order of test cases with different operator signatures is determined based on the following intuitions: Intuition 1: In deep learning library testing, the number of tests with a certain operator signature is large, indicating that the operator may receive more attention due to its complex implementation logic, more edge cases, etc.; Intuition 2: In the test suite equipped with a deep learning compiler, the number of test cases with a certain operator signature is small, indicating that DL compiler developers still pay little attention to the testing of the operator instance transformation; Based on the first and second intuitions, the priority score of the operator is calculated by the ratio of Num_DLL_OPi to Num_DLC_OPi, and the migrated test case set is sorted according to the priority of the operator.
5. The test case migration method for a deep learning compiler according to claim 2, characterized in that: The step 2 further comprises: 2.
2. Sort the migrated test case set according to parameter space diversity: divide the value space of each operator instance parameter into a series of subspaces, each subspace gathers specific values with potential similar test capabilities; specifically, for the parameter value space of integer range, divide it into five subspaces (-∞,-2], [-1], [0], [1] and [2,∞); for the parameter value space of floating point value range, divide it into three subspaces (-∞,0), [0] and (0,∞); for the parameter value space of composite type of tensor, firstly regard each tensor type value as a unique subspace according to the limited tensor type parameter value space, then divide the parameter value space of tensor shape, and use the integer space partitioning method to divide the value space of dimension attributes into seven subspaces [0], [1], [2], [3], [4], [5] and [6,∞), and finally perform intersection operation on each subspace to form the final subspace set of tensor; For an operator signature, based on the subspace of the divided parameter value space, the parameter setting diversity score of the operator instance is measured compared with the parameter setting diversity score of the prioritized operator instance, and the percentage of the new subspace or paired subspace covered by each operator instance parameter or paired parameter combination compared with the prioritized operator instance set is measured to sort the migrated test case set.
6. A test case migration method for a deep learning compiler according to claim 2, characterized in that: The step 2 further comprises: 2.
3. Design a global optimization sorting strategy to prioritize test cases according to the product of the operator signature diversity score and the parameter setting diversity score (i.e., operator instance diversity); after adding the test case with the largest operator instance diversity to the priority results, update the parameter setting diversity of the remaining test cases with the same operator signature for subsequent iterations.
7. A test case migration method for a deep learning compiler according to claim 2, characterized in that: The two test oracles of step 3, namely collapse and reasoning consistency, include: Taking the crash as a test prediction, after filtering invalid test cases, monitor the abnormal termination of the compiler during the deep learning model loading phase; Taking the inference consistency as a test prediction, the output difference between the original model and the compiled model is compared, and the conversion error is determined based on the Chebyshev distance.
8. A test case migration method for a deep learning compiler according to claim 2, characterized in that: The migrated test case is a single-layer deep learning model converted from an operator instance, and its core semantics lies in (1) the signature of the operator and (2) the setting of each parameter in the operator instance.
9. A test case migration method for a deep learning compiler according to claim 2, characterized in that: If the parameter value space is a finite set of concrete values, each unique concrete value in the value space of the dimension attribute is considered as a unique subspace, representing a unique configuration using the operator instance.