Compiler back-end test method, device and equipment, storage medium and product
By obtaining and converting test cases for compiler-specific compilation stages in the fuzzy testing framework, the problem that test cases in the existing technology cannot cover the compilation optimization stage is solved, and the detection efficiency of compilation back-end optimization defects is improved.
Patent Information
- Application Number
- CN202510163359.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-13
- Publication Date
- 2025-06-06
AI Technical Summary
The existing fuzz testing framework fails to consider the compiler's optimization phase characteristics when generating use cases or mutations, resulting in some compilation optimization phases or paths not being passed during pre-analysis, resulting in the test cases not overwriting specific compilation optimization code.
By obtaining the target corpus, extract the test cases for the target compilation phase of the compiler to be tested, and convert it into the compiled input file, and enter the compiler to be tested to determine the test results. The method includes manually constructing and automatically generating test cases, and generating test cases covering more code paths through variant operations in the intermediate representation.
It implements testing for the compiler-specific compilation stage, improves the efficiency of discovering defects in compilation back-end optimization software in fuzzy testing, and ensures that test cases can cover the code analyzed and equivalent transformed in compilation optimization.
Smart Images

Figure CN120104477A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of software testing technology, and in particular to a compiler backend testing method, device, equipment, storage medium and product. Background Art
[0002] The compiler is a core component in the high-performance computing software tool chain and a bridge between the underlying hardware architecture and the upper-level application software. Fuzz testing is a method of discovering software vulnerabilities by providing unexpected inputs to the target system and monitoring abnormal results. By using a large amount of source code generated directly or mutated as the input of the compiler, when the program crashes or memory detection errors occur during operation, software defects in the compilation process can be discovered, which can be further used to detect software vulnerabilities in the compiler and exploit them.
[0003] Compiler optimization mainly includes inter-procedural optimization, pre-optimization, global optimization and loop nesting optimization. Each stage contains a set of serialized paths. However, the current fuzz testing framework does not consider the characteristics of the optimization stage when generating test cases or mutations. This may cause the pre-analysis of a certain stage or a certain path to fail and be skipped directly, making the test case unable to cover the code of the specific compilation optimization. Summary of the invention
[0004] The present invention provides a compiler backend testing method, device, equipment, storage medium and product to implement testing for a specific compilation phase of a compiler.
[0005] According to one aspect of the present invention, a compiler backend testing method is provided, comprising:
[0006] Obtain a target corpus, and extract target test cases from the target corpus; wherein the target test cases are for a target compilation phase of the compiler to be tested;
[0007] Converting the target test case into a compilation input file of the compiler to be tested;
[0008] The compile input file is input into the compiler to be tested, and a test result of the compiler to be tested is determined according to an execution result of the compile input file.
[0009] Further, converting the target test case into a compilation input file of the compiler to be tested includes:
[0010] translating the target test case into an intermediate representation;
[0011] A mutation operation is performed on the intermediate representation to obtain the compilation input file.
[0012] Furthermore, before obtaining the target corpus, the following steps are also included:
[0013] The target corpus is constructed.
[0014] Furthermore, constructing the target corpus includes:
[0015] According to each optimization stage of the compiler, obtaining a first test case manually constructed for each optimization stage;
[0016] Using the test case automatic generation model, a second test case that meets the set grammatical rules and semantic features is automatically generated;
[0017] Inputting the first test case and the second test case into a compiler, extracting a test case that can reach a set compilation stage as a third test case, and determining the coverage of the third test case;
[0018] Reacquire the first test case, adjust the generation strategy of the test case automatic generation model, return to execute the step of inputting the first test case and the second test case into the compiler, until the coverage is greater than or equal to a preset threshold, and put the third test case into the target corpus.
[0019] Furthermore, the first test case contains at least one dependency relationship and / or at least one loop nesting structure.
[0020] Furthermore, before converting the target test case into a compilation input file of the compiler to be tested, the method further includes:
[0021] Obtain an instrumentation whitelist, and perform an instrumentation operation on the compiler to be tested according to the instrumentation whitelist.
[0022] According to another aspect of the present invention, there is provided a compiler backend testing device, comprising:
[0023] A target test case extraction module is used to obtain a target corpus and extract target test cases from the target corpus; wherein the target test cases are for the target compilation stage of the compiler to be tested;
[0024] A target test case conversion module, used for converting the target test case into a compilation input file of the compiler to be tested;
[0025] The test result determination module is used to input the compilation input file into the compiler to be tested, and determine the test result of the compiler to be tested according to the execution result of the compilation input file.
[0026] Optionally, the target test case conversion module is also used to:
[0027] translating the target test case into an intermediate representation;
[0028] A mutation operation is performed on the intermediate representation to obtain the compilation input file.
[0029] Optionally, the device further comprises a target corpus construction module, which is used to construct the target corpus.
[0030] Optionally, the target corpus construction module is also used to:
[0031] According to each optimization stage of the compiler, obtaining a first test case manually constructed for each optimization stage;
[0032] Using the test case automatic generation model, a second test case that meets the set grammatical rules and semantic features is automatically generated;
[0033] Inputting the first test case and the second test case into a compiler, extracting a test case that can reach a set compilation stage as a third test case, and determining the coverage of the third test case;
[0034] Reacquire the first test case, adjust the generation strategy of the test case automatic generation model, return to execute the step of inputting the first test case and the second test case into the compiler, until the coverage is greater than or equal to a preset threshold, and put the third test case into the target corpus.
[0035] Optionally, the first test case contains at least one dependency relationship and / or at least one loop nested structure.
[0036] Optionally, the device further comprises an instrumentation module, which is used to obtain an instrumentation whitelist, and perform an instrumentation operation on the compiler to be tested according to the instrumentation whitelist.
[0037] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:
[0038] at least one processor; and
[0039] a memory communicatively connected to the at least one processor; wherein,
[0040] The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the compiler back-end testing method described in any embodiment of the present invention.
[0041] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the compiler back-end testing method described in any embodiment of the present invention when executed.
[0042] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program / instructions, and the computer program / instructions, when executed by a processor, implement the steps of the compiler back-end testing method described in any embodiment of the present invention.
[0043] The compiler backend testing method disclosed in the present invention first obtains a target corpus and extracts target test cases from the target corpus; wherein the target test cases target the target compilation stage of the compiler to be tested; then the target test cases are converted into a compilation input file of the compiler to be tested; finally, the compilation input file is input into the compiler to be tested, and the test result of the compiler to be tested is determined according to the execution result of the compilation input file. The compiler backend testing method disclosed in the present invention enables the test of the compiler to directly reach a specific compilation stage by making the target test cases target the target compilation stage of the compiler to be tested, and can improve the efficiency of discovering software defects in the compilation backend optimization in fuzzy testing.
[0044] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0045] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0046] Figure 1 is a flowchart of a compiler backend testing method provided according to Embodiment 1 of the present invention;
[0047] Figure 2 is a flowchart of a compiler backend testing method provided according to Embodiment 2 of the present invention;
[0048] Figure 3 is a schematic diagram of the structure of a compiler backend testing device provided according to Embodiment 3 of the present invention;
[0049] Figure 4 It is a structural schematic diagram of an electronic device for implementing the compiler back-end testing method of the fourth embodiment of the present invention. DETAILED DESCRIPTION
[0050] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0051] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0052] Embodiment 1
[0053] Figure 1 This is a flowchart of a compiler backend testing method provided in the first embodiment of the present invention. This embodiment is applicable to the case of performing fuzzy testing on a compiler. The method can be executed by a compiler backend testing device. The compiler backend testing device can be implemented in the form of hardware and / or software. The compiler backend testing device can be configured in an electronic device. Figure 1 As shown, the method includes:
[0054] S110: Obtain a target corpus, and extract target test cases from the target corpus.
[0055] The target corpus is a pre-constructed text library storing test cases, and the target test cases are test cases extracted from the target corpus to test the compiler to be tested. The target test cases are for the target compilation phase of the compiler to be tested, and the compiler to be tested is the object of the test.
[0056] In this embodiment, in order to test the specific compilation stage of the compiler to be tested, a test case that can be received by a specific path constructed according to the characteristics of the specific compilation stage of the compiler to be tested can be obtained from the target corpus as a target test case, so as to cover the code analyzed and equivalently transformed in the compilation optimization as much as possible. Among them, the target compilation stage is the specific compilation stage in the compiler to be tested that the target test case targets. Preferably, the target compilation stage can be the compilation optimization stage of the back end of the compiler, including the inter-procedural optimization stage, the pre-optimization stage, the global optimization stage, and the loop nesting optimization stage. The above stages can be further subdivided, for example, the loop nesting optimization stage includes the vectorization stage, the parallelization stage, the loop unrolling stage, the loop distribution stage, the loop peeling stage, the peephole optimization stage, etc. For example, to test the security defects of the back-end optimization (such as the vectorization module) in the compiler, it is necessary to construct a test case that meets the characteristics of traditional vectorization and SLP vectorization. If the initial test case cannot cover the vectorization module, it is also difficult to generate a test case that meets the optimization characteristics of the vectorization module by relying on subsequent structural mutations.
[0057] S120: Convert the target test case into a compilation input file of the compiler to be tested.
[0058] In this embodiment, after extracting the target test cases from the target corpus, the C / C++ front-end compiler can translate the source code of each test case into an intermediate representation (IR) through lexical analysis, syntax analysis, and semantic analysis, and a mutation operation needs to be performed on the basis of the IR to obtain a compilation input file for input into the compiler to be tested.
[0059] Among them, IR is an intermediate representation that plays an important role in the compilation process. It can help the compiler perform various optimization algorithms and ultimately generate target code. By performing various optimization algorithms on IR, the execution efficiency of the program can be improved. Mutation refers to a technical means of causing changes in program behavior by modifying code logic, parameters, or algorithms during code compilation. By introducing mutations to process test cases, it can help detect the correctness of the compiler in handling various situations. Mutation testing can automatically generate a large number of test cases, covering more code paths and boundary conditions, thereby improving the quality and reliability of the compiler. In addition, mutation testing can also help developers discover defects and vulnerabilities in the compiler and further optimize the performance and stability of the compiler.
[0060] S130 , inputting the compilation input file into the compiler to be tested, and determining the test result of the compiler to be tested according to the execution result of the compilation input file.
[0061] In this embodiment, after the compilation input file obtained after the target test case conversion is input into the compiler to be tested, based on the execution result, that is, whether errors such as interruption occur, it can be determined whether the compiler to be tested can correctly process various inputs and generate correct target code.
[0062] Specifically, after the compiled input file is input into the compiler to be tested, the intermediate code is generated after the correctness verification of the syntax analysis and the correctness verification of the semantic analysis, and a specific compilation optimization stage is reached, thus realizing a "deep" + "precise" fuzz testing process. When a new path is triggered, the current test case can be added to the target corpus to continue the closed-loop fuzz testing process.
[0063] Furthermore, before obtaining the target corpus, you may also: construct the target corpus.
[0064] In this embodiment, in order to implement testing of a specific compilation stage of the compiler to be tested, test cases acceptable to a specific path can be constructed specifically according to the characteristics of the specific compilation stage of the compiler to be tested, and added to the target corpus, thereby implementing the construction of the target corpus.
[0065] Optionally, the method for constructing the target corpus can be:
[0066] According to each optimization stage of the compiler, a first test case manually constructed for each optimization stage is obtained; a second test case that conforms to the set grammatical rules and semantic features is automatically generated using a test case automatic generation model; the first test case and the second test case are input into the compiler, and a test case that can reach the set compilation stage is extracted as a third test case, and the coverage of the third test case is determined; the first test case is re-obtained, and the generation strategy of the test case automatic generation model is adjusted, and the step of inputting the first test case and the second test case into the compiler is returned to execute until the coverage is greater than or equal to a preset threshold, and the third test case is put into the target corpus.
[0067] Specifically, when constructing the target corpus, a method combining manual construction and automatic construction can be adopted. First, obtain the test cases manually constructed according to the characteristics of each optimization stage of the compiler, that is, the first test cases. For example, when constructing test cases for the vectorization stage, it is necessary to combine the functional characteristics of GCC's automatic vectorization to construct traditional vectorization based on loop structures and SLP vectorization based on basic blocks. These two types of vectorization are essentially different. Therefore, they need to be distinguished when automatically constructing test cases. Then, combine the automatic test case generation model (such as the CSmith model), and according to the model generation strategy, automatically generate the second test cases that conform to the set syntax rules and semantic features. The automatic generation of test cases, as a complementary method to manual construction, can effectively improve the problems of low efficiency and small number of generated test cases in manual construction of test cases. Again, use both the first test cases and the second test cases as the input of the compiler. For the test cases that cannot pass the syntax analysis and semantic analysis, directly discard them, and extract the test cases that can reach the set compilation stage as the third test cases. After compiling the third test cases, calculate the corresponding coverage rate C and compare it with the preset threshold T. If C < T, it indicates that the test case does not meet the requirements, and it is necessary to adjust the generation strategy of the test case automatic generation model and perform the next round of testing and coverage rate calculation; if C ≥ T, it indicates that the test case meets the requirements and can be added to the target corpus to complete the construction of the target corpus.
[0068] Optionally, the first test cases include at least one dependency and / or at least one loop nesting structure.
[0069] Specifically, the loop structures in the program often occupy a large amount of running time, and the optimization of loops is also the core function of the compiler backend optimization. The compiler includes a large number of compilation optimization passes such as vectorization. Here, "pass" means pass. In compiler design, "pass" usually refers to the process of the compiler performing multiple traversals on the source code, and each traversal is called a "pass". Studying the strategy for improving the fuzz testing coverage rate of compiler loop nesting optimization can better guide the design of the secure compilation support framework for compiler backend optimization, optimize the fuzz testing process, and improve the efficiency of discovering compiler software defects.
[0070] Among them, the main factor affecting loop transformation is dependency. When there are true dependencies and other dependencies in the loop, a dependency loop will be formed. When the dependency loop cannot be eliminated, it is impossible to pass the analysis of loop unrolling, loop distribution and other stages, and it is impossible to enter the code segment of the loop transformation for execution. By using dependencies to improve the coverage of fuzz testing, various basic dependencies such as true dependency, anti-dependency, loop-carrying dependency, loop-independent dependency and the combination of basic dependencies can be analyzed, and the impact of dependencies on the implementation of different types of loop transformations can be analyzed from a theoretical level, and test cases that meet various dependencies can be constructed artificially. Furthermore, an experimental process can be designed to perform fuzz testing and collect code coverage information of specific loop optimization parts, and the impact of the introduction of a certain dependency on coverage can be analyzed based on the experimental results. For example: when the introduction of loop-carrying true dependencies will lead to a decrease in the coverage of loop unrolling optimization, which requires eliminating this dependency in the IR transformation of specific compilation optimization when designing the fuzz testing framework.
[0071] In addition, the loop transformation structure includes loop nesting, which is a grammatical structure composed of multiple for loops. It can be divided into perfect loop nesting and imperfect loop nesting according to whether other statements are contained between for statements, and can be divided into two-layer loop nesting, three-layer loop nesting and multi-layer loop nesting according to depth. When the characteristics of the loop structure cannot be analyzed through loop expansion, loop distribution and other stages, it is also impossible to enter the code segment of the loop transformation for execution. By using the loop structure to improve the coverage of fuzz testing, various basic loop structure features such as perfect loop nesting, imperfect loop nesting, single-layer loop, two-layer loop nesting, and three-layer loop nesting can be sorted out. By combining the loop structure features of different dimensions, the influence of loop structure on the implementation of different types of loop transformation is analyzed from a theoretical level, and test cases that meet various loop structures are artificially constructed. Furthermore, the experimental process can be designed to perform fuzz testing and collect code coverage information of specific loop optimization parts. According to the experimental results, the program features of the loop structure with higher coverage are analyzed, and the weight of the insertion and replacement mutation operations in the IR transformation is increased to generate the feature test case.
[0072] The compiler backend testing method disclosed in the present invention first obtains a target corpus, extracts target test cases from the target corpus, wherein the target test cases target the target compilation stage of the compiler to be tested, then converts the target test cases into a compilation input file of the compiler to be tested, and finally inputs the compilation input file into the compiler to be tested, and determines the test result of the compiler to be tested according to the execution result of the compilation input file. The compiler backend testing method disclosed in the present invention enables the test of the compiler to directly reach a specific compilation stage by making the target test cases target the target compilation stage of the compiler to be tested, and can improve the efficiency of discovering software defects in the compilation backend optimization in fuzz testing.
[0073] Embodiment 2
[0074] Figure 2 Flow chart of a compiler backend testing method provided in Embodiment 2 of the present invention. This embodiment is a refinement of the above embodiment. Figure 2 As shown, the method includes:
[0075] S210: Obtain a target corpus, and extract target test cases from the target corpus.
[0076] Among them, the target test case is aimed at the target compilation stage of the compiler to be tested.
[0077] In this embodiment, in order to test a specific compilation phase of the compiler to be tested, a test case that can be received by a specific path constructed according to the characteristics of the specific compilation phase of the compiler to be tested can be obtained from the target corpus as a target test case, so as to cover the code analyzed and equivalently transformed in the compilation optimization as much as possible. Among them, the target compilation phase is the specific compilation phase of the compiler to be tested that is targeted by the target test case. Preferably, the target compilation phase can be the compilation optimization phase of the compiler backend.
[0078] S220: Translate the target test case into an intermediate representation, perform a mutation operation on the intermediate representation, and obtain a compilation input file.
[0079] In this embodiment, after obtaining the target test case, the target test case can be translated into an intermediate representation (IR) by a C / C++ front-end compiler. Based on the IR, a mutation operation is also required to convert the IR into a compilation input file for the input compiler.
[0080] Optionally, the step of translating the target test case into an intermediate representation includes lexical analysis, syntactic analysis and semantic analysis, and the step of mutating the intermediate representation includes constrained mutation considering language characteristics, semantic correction, IR transformation for specific compilation optimization, and IR2Source transformation.
[0081] Specifically, since the execution of the mutation operation may generate test cases with syntax errors, it is necessary to analyze the test cases generated after the mutation and discarded in the syntax analysis process, and perform syntax correction in the constraint mutation according to the actual syntax characteristics. In semantic correction, invalid variables need to be replaced with valid variables to avoid undefined or out-of-scope variables, thereby ensuring the correctness of semantic verification. Although semantic correction can ensure that the test case generates intermediate code through the compiler front end and enters the complex compilation optimization part of multiple stages, whether the back-end optimization can be deeply covered requires the transformation of the intermediate representation IR for specific compilation optimization after semantic correction. For example: when fuzz testing software defects of loop nesting optimization LNO, it is necessary to try to avoid introducing loop dependencies in the for loop, which will cause the test case to fail to cover a large number of equivalent transformation codes in LNO, such as loop distribution and loop unrolling. After adding IR transformation for loop nesting optimization LNO to the safe compilation support framework for compiler back-end optimization, statements containing loop-carried dependencies and loop-independent dependencies can be transformed into other IRs, eliminating the dependencies that restrict loop transformation and covering more LNO code. IR2Source transformation is a process of converting intermediate representation (IR) code back to source code. Since the designed intermediate representation is close to the source language and carries the information of the source language, IR2Source transforms the intermediate representation back into C / C++ source code.
[0082] S230 , inputting the compilation input file into the compiler to be tested, and determining the test result of the compiler to be tested according to the execution result of the compilation input file.
[0083] In this embodiment, after the compilation input file obtained after the target test case conversion is input into the compiler to be tested, based on the execution result, that is, whether errors such as interruption occur, it can be determined whether the compiler to be tested can correctly process various inputs and generate correct target code.
[0084] Furthermore, before converting the target test case into a compilation input file of the compiler to be tested, it is also possible to: obtain an instrumentation whitelist, and perform an instrumentation operation on the compiler to be tested according to the instrumentation whitelist.
[0085] Specifically, compiler plugging refers to modifying existing code or generating new code during the compilation process to achieve specific functions. The core idea is to insert additional code at a specific location in the source code to achieve performance analysis, debugging, code coverage statistics and other purposes. When plugging the compiler in the fuzz test of the prior art, each basic block of the entire file is usually plugged indiscriminately. This method does not need to analyze the function of the compiler, and the test efficiency is higher when used for smaller files. However, the compiler has about 6 million lines of source code, which is very large. If all basic blocks of the entire compiler are plugged, a lot of feedback edge coverage information has nothing to do with specific compilation optimization code segments (such as syntax analysis and semantic analysis with good robustness), which not only affects the efficiency of plugging compilation, but also greatly affects the efficiency of fuzz testing. Therefore, in order to improve the efficiency of fuzz testing, the compiler can be selectively plugged according to the preset plugging whitelist and the information in the plugging whitelist. The plugging whitelist can be determined by analyzing the paths that affect vectorization in loop nesting optimization, and these paths that affect vectorization can be formed into a plugging whitelist in the form of files or function names.
[0086] The compiler backend testing method provided by the embodiment of the present invention can improve the efficiency of discovering software defects in the compiler backend optimization in fuzz testing by making the target test case target the target compilation stage of the compiler to be tested, so that the test of the compiler can directly reach the specific compilation stage. In addition, by performing compiler plugging according to the preset plugging whitelist, the testing efficiency can be improved.
[0087] Embodiment 3
[0088] Figure 3 A schematic diagram of the structure of a compiler backend testing device provided in Embodiment 3 of the present invention is shown in FIG. Figure 3 As shown, the device includes: a target test case extraction module 310, a target test case conversion module 320 and a test result determination module 330.
[0089] The target test case extraction module 310 is used to obtain a target corpus and extract target test cases from the target corpus.
[0090] Among them, the target test case is aimed at the target compilation stage of the compiler to be tested.
[0091] The target test case conversion module 320 is used to convert the target test case into a compilation input file of the compiler to be tested.
[0092] The test result determination module 330 is used to input the compilation input file into the compiler to be tested, and determine the test result of the compiler to be tested according to the execution result of the compilation input file.
[0093] Optionally, the target test case conversion module 320 is further used to:
[0094] Translate the target test case into an intermediate representation; perform mutation operations on the intermediate representation to obtain a compilation input file.
[0095] Optionally, the device further includes a target corpus construction module, which is used to construct a target corpus.
[0096] Optionally, the target corpus construction module is also used to:
[0097] According to each optimization stage of the compiler, a first test case manually constructed for each optimization stage is obtained; a second test case that conforms to the set grammatical rules and semantic features is automatically generated using a test case automatic generation model; the first test case and the second test case are input into the compiler, and a test case that can reach the set compilation stage is extracted as a third test case, and the coverage of the third test case is determined; the first test case is re-obtained, and the generation strategy of the test case automatic generation model is adjusted, and the step of inputting the first test case and the second test case into the compiler is returned to execute until the coverage is greater than or equal to a preset threshold, and the third test case is put into the target corpus.
[0098] Optionally, the first test case includes at least one dependency relationship and / or at least one loop nesting structure.
[0099] Optionally, the device further includes an instrumentation module, which is used to obtain an instrumentation whitelist and perform an instrumentation operation on the compiler to be tested according to the instrumentation whitelist.
[0100] The compiler backend testing device provided in the embodiment of the present invention can execute the compiler backend testing method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0101] Embodiment 4
[0102] Figure 4 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.
[0103] like Figure 4As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0104] A number of components in the electronic device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.
[0105] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as a compiler backend testing method.
[0106] In some embodiments, the compiler back-end testing method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the compiler back-end testing described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to execute the compiler back-end testing method in any other appropriate manner (e.g., by means of firmware).
[0107] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0108] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.
[0109] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0110] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).
[0111] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.
[0112] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.
Claims
1. A compiler backend testing method, characterized in that: include: Obtain a target corpus, and extract target test cases from the target corpus; wherein the target test cases are for a target compilation phase of the compiler to be tested; Converting the target test case into a compilation input file of the compiler to be tested; The compile input file is input into the compiler to be tested, and a test result of the compiler to be tested is determined according to an execution result of the compile input file.
2. The method according to claim 1, characterized in that Convert the target test case into a compilation input file of the compiler to be tested, including: translating the target test case into an intermediate representation; A mutation operation is performed on the intermediate representation to obtain the compilation input file.
3. The method according to claim 1, characterized in that Before obtaining the target corpus, it also includes: The target corpus is constructed.
4. The method according to claim 3, characterized in that Constructing the target corpus includes: According to each optimization stage of the compiler, obtaining a first test case manually constructed for each optimization stage; Using the test case automatic generation model, a second test case that meets the set grammatical rules and semantic features is automatically generated; Inputting the first test case and the second test case into a compiler, extracting a test case that can reach a set compilation stage as a third test case, and determining the coverage of the third test case; Reacquire the first test case, adjust the generation strategy of the test case automatic generation model, return to execute the step of inputting the first test case and the second test case into the compiler, until the coverage is greater than or equal to a preset threshold, and put the third test case into the target corpus.
5. The method according to claim 4, characterized in that The first test case contains at least one dependency relationship and / or at least one loop nesting structure.
6. The method according to claim 1, characterized in that Before converting the target test case into a compilation input file of the compiler to be tested, the method further includes: Obtain an instrumentation whitelist, and perform an instrumentation operation on the compiler to be tested according to the instrumentation whitelist.
7. A compiler backend testing device, characterized in that: include: A target test case extraction module is used to obtain a target corpus and extract target test cases from the target corpus; wherein the target test cases are for the target compilation stage of the compiler to be tested; A target test case conversion module, used for converting the target test case into a compilation input file of the compiler to be tested; The test result determination module is used to input the compilation input file into the compiler to be tested, and determine the test result of the compiler to be tested according to the execution result of the compilation input file.
8. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the compiler back-end testing method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the compiler back-end testing method according to any one of claims 1 to 6 when executed.
10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of the compiler back-end testing method according to any one of claims 1 to 6 are implemented.