Compiler automatic debugging method and system for VLIW and SIMD architecture

Abstract

The application discloses a kind of compiler automatic debugging method and system for VLIW and SIMD architecture, the method of the application includes the semantic correctness verification for the program to be checked to judge whether the program to be checked exists semantic error relative to source program, if semantic correctness verification finds that there is semantic error, then determine that debugging is not passed, otherwise the physical register verification for the program to be checked to judge whether the program to be checked exists physical register allocation error, if there is physical register allocation error, then determine that debugging is not passed, otherwise determine that debugging is passed;When determining that debugging is not passed, then generate feedback verification report.The application can automatically check the semantic correctness of program in the process of compiling, and provide accurate verification report (including error occurrence position and type etc.) for developer, improve the efficiency of compiler development, reduce the burden of developer.

Description

Technical Field

[0001] This invention relates to the field of compiler debugging technology, and specifically to an automatic debugging method and system for compilers with VLIW and SIMD architectures. Background Technology

[0002] DSP (Digital Signal Processor) includes VLIW (Very Long Instruction Word) and SIMD (Single Instruction Stream Multiple Data) architectures. Its characteristics are multi-instruction parallelism, which can provide high throughput and high parallelism for digital signal processing through vector units, further improving processor performance.

[0003] The performance of VLIW and SIMD architecture DSPs largely depends on the exploitation of instruction-level parallelism. However, this architecture lacks hardware support for instruction scheduling, requiring compilers to implement parallel instruction execution. Therefore, compared to other architectures (such as superscalar), VLIW and SIMD architecture compilers are more difficult to develop and more complex to implement. The compiler's function is to translate a source language (usually a high-level language) into a target language (usually assembly language). The compilation process includes code parsing, instruction selection, instruction scheduling, and register allocation. During compilation, the compiler optimizes the program to improve performance, primarily through instruction scheduling and register allocation. The source language is first parsed and translated into an intermediate representation (IR) as input. Then, the compiler performs fine-grained instruction-level optimizations. The IR consists of machine instructions, which differ from assembly instructions in that assembly instructions use physical registers as operands, while IR machine instructions use virtual registers. During the instruction scheduling phase, the compiler reorders instructions, reconstructs the source program, and generates a complete scheduling scheme composed of machine instructions. During the register allocation phase, physical registers are allocated to machine instructions, replacing the original virtual registers, and generating an assembly program as output. In this process, there are three different versions of the program: the source program represented by the instruction reordering (IR), the intermediate result represented by the IR, and the final generated assembly program. The intermediate result represented by the IR is a transitional program obtained by scheduling the source program; it is still composed of IR machine instructions, but differs from the source program in that its instructions have been rearranged. The basic goal of compiler development is to ensure that the target program (i.e., the assembly program) can execute correctly, that is, to ensure the semantic correctness of the program. However, in practical applications, compilers often need to handle various complex input programs, and during compilation, code reconstructing due to instruction reordering and the need to handle different types of operands result in numerous factors that compiler developers need to consider. Manual development has limitations, and compilers inevitably contain various vulnerabilities during development. These compiler vulnerabilities will ultimately lead to semantic errors in the target program (i.e., the assembly program). Factors causing semantic errors can be categorized into the following three types based on the stage at which they occur: 1) Instruction parsing errors. During the parsing phase, basic instruction information (such as execution cycle and corresponding functional unit) needs to be read. If incorrect information is read during this process, it will lead to decision errors in the subsequent optimization phase, resulting in incorrect execution results in the final generated assembly code; 2) Scheduling policy errors. During the instruction scheduling phase, if the scheduling policy is incorrect (for example, the actual number of parallel instructions exceeds the functional unit limit), it will lead to incorrect instruction sorting and packing; 3) Physical register allocation errors.During the register allocation phase, the compiler assigns physical registers to instructions, replacing the original virtual registers. Different functions of instructions require corresponding types of physical registers. Due to the diversity of physical register types and the limitations on their quantity, issues such as code overflow can easily occur, leading to access conflicts during the allocation process. These errors are hidden in the compilation process, and for developers, discovering them usually requires manual intervention, checking each instruction one by one. This is undoubtedly a difficult and tedious task, greatly limiting the efficiency of compiler development. Summary of the Invention

[0004] The technical problem this invention aims to solve is to provide an automatic compiler debugging method and system for VLIW and SIMD architectures, addressing the aforementioned problems existing in current compiler debugging methods. This invention can automatically check the semantic correctness of the program during the compilation process, while providing developers with accurate verification reports (including the location and type of errors), thereby improving the efficiency of compiler development and reducing the burden on developers.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0006] An automated debugging method for compilers targeting VLIW and SIMD architectures includes:

[0007] S101, Perform semantic correctness verification on the program to be verified to determine whether there is a semantic error in the program to be verified relative to the source program. If the semantic correctness verification finds a semantic error, jump to step S103; otherwise, jump to step S102.

[0008] S102, Perform physical register verification on the program to be verified to determine whether there is a physical register allocation error in the program to be verified. If there is a physical register allocation error, jump to step S103; otherwise, determine that the debugging is successful, end and exit.

[0009] S103, the debugging process fails, a feedback verification report is generated, and the process ends and exits.

[0010] Optionally, the semantic correctness verification in step S101 includes:

[0011] S201, Record the data streams of the program to be verified and its source program respectively. The program to be verified is an intermediate result or an assembly program. The data streams consist of a sequence of instructions and operands.

[0012] S202, traverse the data stream to obtain an operand as the current operand. If the traversal is successful, jump to step S203. If the traversal is complete, determine that the program to be verified does not have semantic errors relative to the source program, end and exit.

[0013] S203, For the current operand, compare the data streams of the program to be verified and its source program respectively. If the instructions recorded in the data streams of the program to be verified and its source program are consistent, it is determined that the comparison of the current operand is successful and jump to step S202; otherwise, it is determined that the comparison of the current operand is unsuccessful and jump to step S204.

[0014] S204, retrieve and determine the error location where the current operand comparison fails, determine the error type corresponding to the current operand comparison failure, and record the verification information for use in generating a feedback verification report.

[0015] Optionally, step S201 includes:

[0016] 301 represents the numbering of the instructions and operands in the program to be verified and its source program, respectively.

[0017] 302, which performs instruction parsing on the program to be verified and its source program respectively, and numbers all instructions starting from 0 according to the reading order;

[0018] 303 assigns operand numbers to all operands of instructions. If an operand is defined in an instruction, the operand number is assigned to the operand number of the instruction that defined it. If an operand is used in an instruction, the instruction sequence is traversed backwards from the current instruction to find the instruction that last defined the operand, and the operand number is assigned to the operand number of the instruction that defined it.

[0019] Optionally, when numbering the instructions and operands in the program to be verified and its source program in step 301, the initial value of the instruction and operand numbers is -1.

[0020] Optionally, when determining the error type corresponding to the current operand comparison failure in step S204, it includes determining the error type corresponding to the current operand comparison failure as a write-after-write error, a read-after-write error, or a write-after-read error based on the order of instructions in the instruction pair corresponding to the current operand comparison failure.

[0021] Optionally, the physical register verification in step S102 includes:

[0022] S401 establishes a one-to-one operand mapping relationship between the physical registers in the program to be verified and the virtual registers in the source program.

[0023] S402, for the program to be verified and its source program, traverse the instructions in the time sequence respectively, and record the life cycle for the operands defined in the program to be verified and its source program respectively;

[0024] S403, traverse and obtain one operand in the program to be verified as the current operand. If the traversal is successful, jump to step S404. If the traversal is completed, determine that the program to be verified does not have semantic errors relative to the source program, end and exit.

[0025] S404, determine whether there is an overlap between the lifetime of the current operand in the program to be verified and its lifetime in the source program. If there is no overlap, proceed to step S403; otherwise, proceed to step S405.

[0026] S405, retrieve and determine the error location where the current operand has periodic overlap, determine the error type where the current operand has periodic overlap, and record the verification information for use in generating a feedback verification report.

[0027] Optionally, when recording the lifecycle in step S402, the operation for each operand includes: for a given operand op, recording the time slot t1 when op is first defined, and taking t1 as the starting point of op's lifecycle; starting from t1, sequentially traversing the time series, finding the time slot t2 when op is next defined, and taking t2 as the end point of op's lifecycle, finally obtaining the lifecycle [t1, t2] of operand op; if there is a definition for the operand in the subsequent time series, then updating the lifecycle of the operand, taking the end point of the operand's lifecycle as the starting point, and taking the time slot when the operand is currently defined as the end point of the operand's lifecycle.

[0028] Optionally, when determining the error type of periodic overlap in the current operand in step S405, it includes determining the error type of the current operand comparison failure as a write-after-write error, a read-after-write error, or a write-after-read error based on the order of instructions in the instruction pair that the current operand comparison fails.

[0029] Furthermore, the present invention also provides an automatic compiler debugging system for VLIW and SIMD architectures, including interconnected microprocessors and memory, wherein the microprocessors are programmed or configured to execute the automatic compiler debugging method for VLIW and SIMD architectures.

[0030] Furthermore, the present invention also provides a computer-readable storage medium storing a computer program for being programmed or configured by a microprocessor to execute the claimed compiler automatic debugging method for VLIW and SIMD architectures.

[0031] Compared with existing technologies, the present invention has the following advantages: By tracing the compilation process and checking the semantics of each compilation stage, the present invention can accurately locate the error location and type without manual intervention, providing instruction-level debugging for VLIW and SIMD architecture compilers. In particular, the present invention includes program semantic correctness verification and physical register verification, which can automatically check the semantic correctness of the program during the compilation process, and at the same time provide developers with accurate verification reports (including the location and type of error, etc.), improving the efficiency of compiler development and reducing the burden on developers. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0033] Figure 2 This is a schematic diagram of the semantic correctness verification process proposed in this invention.

[0034] Figure 3 This is a schematic diagram of the data stream recording process in an embodiment of the present invention.

[0035] Figure 4 This is a schematic diagram of the physical register verification process proposed in this invention. Detailed Implementation

[0036] The present invention will be further described in detail below with reference to embodiments and accompanying drawings.

[0037] like Figure 1 As shown, the compiler automatic debugging method for VLIW and SIMD architectures in this embodiment includes:

[0038] S101, Perform semantic correctness verification on the program to be verified (intermediate result or assembly program) to determine whether there is a semantic error in the program to be verified relative to the source program. If the semantic correctness verification finds a semantic error, jump to step S103; otherwise, jump to step S102.

[0039] S102, Perform physical register verification on the program to be verified to determine whether there is a physical register allocation error in the program to be verified. If there is a physical register allocation error, jump to step S103; otherwise, determine that the debugging is successful, end and exit.

[0040] S103, the debugging process fails, a feedback verification report is generated, and the process ends and exits.

[0041] See Figure 1 As can be seen, the automatic debugging method for compilers of VLIW and SIMD architectures in this embodiment mainly consists of two functions: semantic correctness verification and physical register verification.

[0042] The purpose of semantic correctness verification is to determine whether there are semantic errors in the intermediate results and the assembler compared with the source program; such as Figure 2 As shown, the semantic correctness verification in step S101 of this embodiment includes:

[0043] S201, record the data streams of the program to be verified and its source program respectively. The program to be verified is an intermediate result or an assembly program. The data stream consists of a sequence of instructions and operands. Since the original intention of the user's programming cannot be obtained, it is assumed that there are no semantic errors in the source program and it is used as a control group.

[0044] S202, traverse the data stream to obtain an operand as the current operand. If the traversal is successful, jump to step S203. If the traversal is complete, determine that the program to be verified does not have semantic errors relative to the source program, end and exit.

[0045] S203, For the current operand, compare the data streams of the program to be verified and its source program respectively. If the instructions recorded in the data streams of the program to be verified and its source program are consistent, it is determined that the comparison of the current operand is successful and jump to step S202; otherwise, it is determined that the comparison of the current operand is unsuccessful and jump to step S204.

[0046] S204, retrieve and determine the error location where the current operand comparison fails, determine the error type corresponding to the current operand comparison failure, and record the verification information for use in generating a feedback verification report.

[0047] In this embodiment, step S201 includes:

[0048] 301 represents the numbering of the instructions and operands in the program to be verified and its source program, respectively.

[0049] 302, which performs instruction parsing on the program to be verified and its source program respectively, and numbers all instructions starting from 0 according to the reading order;

[0050] Step 303 assigns operand numbers to all instruction operands. If an operand is defined within an instruction, the operand number is assigned the number of the instruction that defined it. If an operand is used within an instruction, the instruction sequence is traversed backwards from the current instruction to find the most recent instruction that defined the operand, and the operand number is assigned the number of that instruction. In this embodiment, when numbering the instructions and operands in the program to be verified and its source program in step 301, the initial values ​​of both instruction and operand numbers are -1.

[0051] At this point, all instructions and operands have been numbered, and each instruction and its operand number constitutes a record node. Since the method in this embodiment is based on data flow, the execution of the program can be equivalent to the process of updating each operand. Therefore, it is also necessary to record and save the updates (i.e., definitions) of each operand.

[0052] by Figure 3 For example, instructions are numbered from 0 to 2 according to the reading order. Instruction VFADDS32 defines operand VR2, so instruction number 0 is assigned to the corresponding number of VR2 in VFADDS32. The assignment process for other operands is similar. Instruction VFMULS32 uses VR2 defined by VFADDS32 and VR4 defined by VMOV, so the numbers of the two operands in VFADDS32 are assigned 0 and 1 respectively, thus completing the instruction and operand numbering. The essence of data flow is the process of data updating, which is represented in the program as the process of defining operands. Taking VR2 as an example, the records corresponding to the instructions defining VR2 are saved in the order of their effectiveness, thus completing the data flow recording for VR2.

[0053] In this embodiment, when determining the error type corresponding to the current operand comparison failure in step S204, it includes determining the error type corresponding to the current operand comparison failure as a write-after-write error, a read-after-write error, or a write-after-read error based on the order of instructions in the instruction pair corresponding to the current operand comparison failure. Two records in the source program and the program to be verified have inconsistent data flows, and these two records correspond to two instructions that define the current operand. Semantic errors manifest as errors in the dependency relationships (write-after-write, read-after-write, and write-after-read) of instructions in the verification program (intermediate results and assembly program), while in the data flow records, they manifest as errors in the record order. Therefore, the error type can be determined simply by the dependency relationships between the instructions corresponding to the two records. For example, there are two instructions with a write-after-write dependency, which share a common operand 'a', and the corresponding numbers of the two instructions have a sequential order in the record of operand 'a'. If there is a write-after-write conflict between the two instructions defining operand 'a', the order of the corresponding numbers of the two instructions will change in the operand 'a' record of the program to be verified, thus determining the error type as a write-after-write conflict of operand 'a'. The other two error types can be judged similarly;

[0054] like Figure 4 As shown, the physical register verification in step S102 of this embodiment includes:

[0055] S401 establishes a one-to-one operand mapping relationship between the physical registers in the program to be verified and the virtual registers in the source program.

[0056] S402, for the program to be verified and its source program, traverse the instructions in the time sequence respectively, and record the life cycle for the operands defined in the program to be verified and its source program respectively;

[0057] S403, traverse and obtain one operand in the program to be verified as the current operand. If the traversal is successful, jump to step S404. If the traversal is completed, determine that the program to be verified does not have semantic errors relative to the source program, end and exit.

[0058] S404, determine whether there is an overlap between the lifetime of the current operand in the program to be verified and its lifetime in the source program. If there is no overlap, proceed to step S403; otherwise, proceed to step S405.

[0059] S405, retrieve and determine the error location where the current operand has periodic overlap, determine the error type where the current operand has periodic overlap, and record the verification information for use in generating a feedback verification report.

[0060] In this embodiment, when recording the lifecycle in step S402, the operation for each operand includes: for a given operand op, recording the time slot t1 when op is first defined, and taking t1 as the starting point of op's lifecycle; starting from t1, sequentially traversing the time sequence, finding the time slot t2 when op is next defined, and taking t2 as the end point of op's lifecycle, finally obtaining the lifecycle [t1, t2] of operand op; if there is a definition for the operand in the subsequent time sequence, then updating the lifecycle of the operand, taking the end point of the operand's lifecycle as the starting point, and taking the time slot when the operand is currently defined as the end point of the operand's lifecycle.

[0061] Physical register allocation errors ultimately manifest as errors in instruction dependencies, and their error types can be determined by referring to the error type judgment method in the semantic correctness verification module. In this embodiment, when determining the error type of periodic overlap in the current operand in step S405, it includes determining the error type of the current operand comparison failure as a write-after-write error, read-after-write error, or write-after-read error based on the order of instructions in the corresponding instruction pair that the current operand does not pass comparison.

[0062] In compiler development, the primary goal is to ensure that the compiler generates correctly executable target programs. However, in practice, the compilation environment is complex and diverse, and coupled with the limitations of developers, compilers inevitably contain various vulnerabilities. The most traditional and direct solution is manual debugging. Developers need to check each instruction one by one during debugging and obtain accurate error information to uncover compiler vulnerabilities, which is undoubtedly a complex and time-consuming task. Especially when dealing with large-scale input programs (more than 500 instructions), manual checking not only consumes more time and effort but is also prone to omissions. Therefore, this embodiment, aiming to save human resources and improve development efficiency, designs a dataflow-based automatic compiler debugging method and system for VLIW and SIMD architectures. By numbering and recording program instructions, it can automatically track the data update status of the source program during compilation. Finally, by comparing the data flow update records, it determines whether semantic errors have occurred in the source program during compilation. At the same time, through data record search, it provides developers with accurate error location and error type information, thereby accelerating the compiler development process.

[0063] Register allocation is the process of replacing virtual registers in machine instructions with physical registers. Physical registers are valuable hardware resources, categorized into different types based on function, and each type has a limited number. Therefore, register reuse and overflow techniques are needed during allocation to alleviate register pressure. Register overflow introduces new access instructions into the program, altering its original structure; in practice, register overflow occurs frequently. Clearly, physical register allocation is a complex and challenging task in compiler development, and compilers are prone to exposing vulnerabilities at this stage. Therefore, this embodiment proposes a lifecycle-based register verification method. By checking the read and write status of physical registers throughout their lifecycle, it can effectively check the correctness of physical register allocation and provide developers with corresponding verification reports.

[0064] In summary, the purpose of this embodiment is to liberate developers from debugging VLIW and SIMD architecture compilers. It provides developers with accurate error location and type information, allowing them to focus on debugging the compiler based on the debugging methods and system feedback. This embodiment automatically checks whether the source program maintains semantic consistency during compilation and verifies the correctness of physical register allocation without manual intervention. Finally, it provides developers with a verification report, including error location and type, thereby saving compiler development time and labor costs.

[0065] Furthermore, this embodiment also provides an automatic compiler debugging system for VLIW and SIMD architectures, including an interconnected microprocessor and memory, wherein the microprocessor is programmed or configured to execute the automatic compiler debugging method for VLIW and SIMD architectures. Additionally, this embodiment also provides a computer-readable storage medium storing a computer program for being programmed or configured by the microprocessor to execute the automatic compiler debugging method for VLIW and SIMD architectures.

[0066] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0067] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. An automatic debugging method for compilers targeting VLIW and SIMD architectures, characterized in that, include: S101, Perform semantic correctness verification on the program to be verified to determine whether there is a semantic error in the program to be verified relative to the source program. If the semantic correctness verification finds a semantic error, jump to step S103; otherwise, jump to step S102. S102, Perform physical register verification on the program to be verified to determine whether there is a physical register allocation error in the program to be verified. If there is a physical register allocation error, jump to step S103; otherwise, determine that the debugging is successful, end and exit. S103, the debugging process fails, a feedback verification report is generated, and the process ends and exits.

2. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 1, characterized in that, The semantic correctness verification in step S101 includes: S201, Record the data streams of the program to be verified and its source program respectively. The program to be verified is an intermediate result or an assembly program. The data streams consist of a sequence of instructions and operands. S202, traverse the data stream to obtain an operand as the current operand. If the traversal is successful, jump to step S203. If the traversal is complete, determine that the program to be verified does not have semantic errors relative to the source program, end and exit. S203, For the current operand, compare the data streams of the program to be verified and its source program respectively. If the instructions recorded in the data streams of the program to be verified and its source program are consistent, it is determined that the comparison of the current operand is successful and jump to step S202; otherwise, it is determined that the comparison of the current operand is unsuccessful and jump to step S204. S204, retrieve and determine the error location where the current operand comparison fails, determine the error type corresponding to the current operand comparison failure, and record the verification information for use in generating a feedback verification report.

3. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 2, characterized in that, Step S201 includes: 301 represents the numbering of the instructions and operands in the program to be verified and its source program, respectively. 302, which performs instruction parsing on the program to be verified and its source program respectively, and numbers all instructions starting from 0 according to the reading order; 303 assigns operand numbers to all operands of instructions. If an operand is defined in an instruction, the operand number is assigned to the operand number of the instruction that defined it. If an operand is used in an instruction, the instruction sequence is traversed backwards from the current instruction to find the instruction that last defined the operand, and the operand number is assigned to the operand number of the instruction that defined it.

4. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 3, characterized in that, When numbering the instructions and operands in the program to be verified and its source program in step 301, the initial value of the instruction and operand numbers is -1.

5. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 2, characterized in that, When determining the error type corresponding to the current operand comparison failure in step S204, it includes determining the error type corresponding to the current operand comparison failure as write-after-write error, read-after-write error, or write-after-read error based on the order of instructions in the instruction pair corresponding to the current operand comparison failure.

6. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 1, characterized in that, Step S102, physical register verification, includes: S401 establishes a one-to-one operand mapping relationship between the physical registers in the program to be verified and the virtual registers in the source program. S402, for the program to be verified and its source program, traverse the instructions in the time sequence respectively, and record the life cycle for the operands defined in the program to be verified and its source program respectively; S403, traverse and obtain one operand in the program to be verified as the current operand. If the traversal is successful, jump to step S404. If the traversal is completed, determine that the program to be verified does not have semantic errors relative to the source program, end and exit. S404, determine whether there is an overlap between the lifetime of the current operand in the program to be verified and its lifetime in the source program. If there is no overlap, proceed to step S403; otherwise, proceed to step S405. S405, retrieve and determine the error location where the current operand has periodic overlap, determine the error type where the current operand has periodic overlap, and record the verification information for generating a feedback verification report.

7. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 6, characterized in that, In step S402, when recording the lifecycle, the operations for each operand include: for a given operand op, record the time slot t1 when op is first defined, and take t1 as the starting point of op's lifecycle; starting from t1, traverse the time series sequentially, find the time slot t2 when op is next defined, and take t2 as the end point of op's lifecycle, finally obtaining the lifecycle [t1, t2] of operand op; if there is a definition for the operand in the subsequent time series, update the lifecycle of the operand, take the end point of the operand's lifecycle as the starting point, and take the time slot when the operand is currently defined as the end point of the operand's lifecycle.

8. The compiler automatic debugging method for VLIW and SIMD architectures according to claim 7, characterized in that, When determining the error type of periodic overlap in the current operand in step S405, it includes determining the error type of the current operand comparison failure as a write-after-write error, a read-after-write error, or a write-after-read error based on the order of instructions in the instruction pair that the current operand does not pass.

9. An automatic compiler debugging system for VLIW and SIMD architectures, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the compiler automatic debugging method for VLIW and SIMD architectures as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, The computer program is used to be programmed or configured by a microprocessor to execute the compiler automatic debugging method for VLIW and SIMD architectures as described in any one of claims 1 to 8.

Images