A basic block based compiler optimization method, system, medium, and device

Abstract

This invention discloses a compiler optimization method, system, medium, and device based on basic blocks. The method includes: obtaining a machine code function to be optimized, the machine code function including several basic blocks; sequentially performing optimization operations on each basic block to obtain an optimized machine code function; wherein, for each basic block, the optimization operation includes: identifying instructions to be optimized within the basic block that belong to custom affine operations, the custom affine operations supporting at least two custom operation types; matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization result; and outputting the optimized machine code function so that the hardware device executes the optimized machine code function. This invention can significantly reduce the number of instructions, thereby improving running efficiency, while ensuring the correctness of optimization.

Description

Technical Field

[0001] This invention relates to the field of compiler optimization technology, and in particular to a compiler optimization method, system, computer-readable storage medium, and terminal device based on basic blocks. Background Technology

[0002] In the field of compiler optimization, constant folding is a classic optimization technique. Its core idea is to calculate the value of a constant expression during the compilation phase and directly replace the original expression with the calculation result to avoid repeated calculations at runtime, thereby reducing runtime code size and computational overhead, and thus improving running speed.

[0003] Traditional constant folding techniques mainly include: local constant folding, which means performing constant calculations only within a single basic block; global constant propagation, which means propagating constant information across the control flow graph through data flow analysis; and affine expression analysis, which means identifying affine relationships of the form reg=base+offset (offset refers to a constant, such as reg=base+256), used to optimize address calculations and other scenarios.

[0004] However, the traditional constant folding technique has the following technical problems when applied to the compiler backend: (1) Single operation type: The traditional constant folding technique usually only supports affine propagation of addition operation and cannot handle other operation types; (2) Cross-type composition error: Even if it can support other operation types, it cannot correctly identify the non-combinability between operations of different operation types, which may lead to incorrect optimization; (3) Missing modifier processing: Instructions usually have modifiers (such as source operand inversion), and the traditional constant folding technique does not consider the case of inconsistent modifiers of different instructions, which may also lead to incorrect optimization. Summary of the Invention

[0005] The purpose of this invention is to provide a compiler optimization method, system, computer-readable storage medium, and terminal device based on basic blocks. This method supports affine propagation of multiple operation types, merges multiple chained operation instructions into a single instruction, significantly reduces the number of instructions, and thus improves running efficiency. At the same time, through strict operation type and modifier matching checks, it can identify the non-combinability between instructions with different operation types and different modifiers, thereby ensuring the correctness of the optimization.

[0006] To achieve the above objectives, embodiments of the present invention provide a compiler optimization method based on basic blocks, comprising: Obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; Optimization operations are performed sequentially on each basic block to obtain optimized machine code functions. For each basic block, the optimization operation includes: identifying instructions to be optimized that belong to custom affine operations within the basic block, wherein the custom affine operations support at least two custom operation types; matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization results. The optimized machine code function is output so that the hardware device executes the optimized machine code function.

[0007] Furthermore, the instructions to be optimized that belong to the custom affine operation contained within the basic identification block specifically include: For each instruction contained within a basic block, the operation type of the instruction is identified based on the instruction's opcode; Determine whether an instruction belongs to a custom affine operation based on the operation type of the instruction and the custom operation types supported by the custom affine operation. When the operation type of an instruction is one of the custom operation types, the instruction is determined to be a custom affine operation, and the instruction that belongs to the custom affine operation is designated as an instruction to be optimized.

[0008] Furthermore, the step of matching the operation type and modifier of the instruction to be optimized according to the preset affine factor mapping table specifically includes: For each instruction to be optimized, extract the source register and immediate value of the instruction; Determine whether the target affine factor corresponding to the source register of the instruction to be optimized exists in the preset affine factor mapping table; If it exists, then determine whether the operation type and modifier of the instruction to be optimized are the same as those of the target affine factor; If they are the same, then the instruction to be optimized is determined to be a successful match with the target affine factor.

[0009] Furthermore, the step of performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization result, specifically includes: The matching instruction to be optimized and the target affine factor are combined and rewritten, and the position of the immediate value in the rewritten instruction is consistent with the position of the immediate value in the target affine factor in the source instruction. The target affine factor is cleared from the affine factor mapping table, and a new affine factor is generated according to the rewritten instructions and written into the affine factor mapping table.

[0010] Furthermore, before performing affine constant folding optimization on the successfully matched instructions to be optimized, the method further includes: Perform boundary overflow checks on the immediate values ​​of the matched instructions to be optimized and the target affine factor; If the check passes, the matching instructions to be optimized are optimized by affine constant folding, and the affine factor mapping table is updated according to the optimization results. If the check fails, the affine constant folding optimization is not performed on the successfully matched instructions to be optimized. Instead, a new affine factor is generated based on the successfully matched instructions to be optimized and written into the affine factor mapping table.

[0011] Furthermore, the method also includes: When there is no target affine factor corresponding to the source register of the instruction to be optimized in the affine factor mapping table, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table; When the operation type of the instruction to be optimized is different from that of the target affine factor, or / and the modifier of the instruction to be optimized is different from that of the target affine factor, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table.

[0012] Furthermore, before writing the new affine factor into the affine factor mapping table, the method further includes: Determine whether the new affine factor is a self-dependent instruction; If it belongs to the category, the new affine factor will not be written into the affine factor mapping table; If it does not belong to the affine factor, then the new affine factor is written into the affine factor mapping table.

[0013] To achieve the above objectives, embodiments of the present invention also provide a compiler optimization system based on basic blocks, comprising: The input module is used to obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; An optimization module is used to sequentially perform optimization operations on each basic block to obtain optimized machine code functions. For each basic block, the optimization operation includes: identifying instructions within the basic block that belong to custom affine operations (the custom affine operations support at least two custom operation types); matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions; and updating the affine factor mapping table based on the optimization results. The output module is used to output the optimized machine code function so that the hardware device executes the optimized machine code function.

[0014] This invention also provides a computer-readable storage medium including a stored computer program, which, when running, controls the device where the computer-readable storage medium is located to execute the compiler optimization method based on basic blocks described above.

[0015] This invention also provides a terminal device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor implements the basic block-based compiler optimization method described above when executing the computer program.

[0016] Compared with existing technologies, embodiments of the present invention provide a compiler optimization method, system, computer-readable storage medium, and terminal device based on basic blocks. First, a machine code function to be optimized is obtained, which includes several basic blocks. Then, optimization operations are performed on each basic block sequentially to obtain an optimized machine code function. For each basic block, the optimization operation includes: identifying instructions within the basic block that belong to custom affine operations (the custom affine operation supports at least two custom operation types); matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions and updating the affine factor mapping table based on the optimization result; finally, outputting the optimized machine code function so that the hardware device can execute the optimized machine code function. Embodiments of the present invention can support affine propagation of multiple operation types, merging multiple chained operation instructions into a single instruction, significantly reducing the number of instructions and thus improving running efficiency. Simultaneously, through strict operation type and modifier matching checks, the incompatibility between instructions with different operation types and different modifiers can be identified, thereby ensuring the correctness of the optimization. Attached Figure Description

[0017] Figure 1 This is a flowchart of a compiler optimization method based on basic blocks provided in an embodiment of the present invention; Figure 2 This is an optimization flowchart of a basic block in a compiler optimization method based on basic blocks provided by an embodiment of the present invention; Figure 3 This is a structural block diagram of a compiler optimization system based on basic blocks provided in an embodiment of the present invention; Figure 4 This is a block diagram of a compiler optimization system based on basic blocks provided in another embodiment of the present invention; Figure 5 This is a structural block diagram of a terminal device provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be noted that, as described in the background section, traditional constant folding techniques mainly include: (1) Local constant folding: constant calculation is performed only within a single basic block. The implementation process is simple, but the optimization scope is limited. (2) Global constant propagation: Propagating constant information within the control flow graph through data flow analysis, which has a wide optimization range but requires complex iterative calculations; (3) Affine expression analysis: Identify affine relationships of the form reg=base+offset (offset refers to a constant, such as reg=base+256), which can be used to optimize address calculation and other scenarios.

[0020] However, traditional constant folding techniques have the following technical problems when applied in the compiler backend: (1) Single operation type: Traditional constant folding technology usually only supports affine propagation of addition operation and cannot handle multiple operation types such as shift, multiplication, and bit operation; (2) Cross-type composition error: Even if other operation types can be supported, the non-combinability between operations of different operation types (such as addition and multiplication operations) cannot be correctly identified, which may lead to incorrect optimization; (3) Missing modifier handling: Instructions usually contain modifiers (such as source operand inversion). Traditional constant folding techniques do not take into account the situation where the modifiers of different instructions are inconsistent, which may also lead to incorrect optimization. (4) Insufficient overflow protection: When merging constants, there is a lack of checks for boundary overflows such as integer overflow and shift out of bounds, which may produce incorrect optimization results; (5) Improper handling of self-dependent instructions: For self-dependent instructions of the form SADD q1, q1, 4, traditional constant folding techniques may produce incorrect affine factor propagation. (6) Inadequate handling of locality of basic blocks: There is a lack of clear handling rules when dealing with scenarios such as Phi nodes and cross-block definitions; among them, Phi nodes are a special instruction in the intermediate representation of the compiler used for static single assignment (SSA), and its function is to dynamically select the correct value of the variable based on the predecessor basic block at the control flow merging node (such as if-else merging, loop entry, etc.).

[0021] To address the aforementioned issues, this invention provides a compiler optimization method based on basic blocks, applied to the compiler backend optimization stage. By tracing affine factors within basic blocks, chained operation instructions are merged into single instructions, thereby significantly reducing the number of instructions and improving execution efficiency. The core idea is to establish a unified affine factorization tracing framework within basic blocks, supporting the identification and combination of multiple operation types. Through strict operation type matching, modifier matching, and overflow protection checks, correct, safe, and efficient chained instruction merging is achieved.

[0022] It should be noted that the embodiments of the present invention are applicable to compiler optimization for various GPU (Graphics Processing Unit) architectures, especially GPU compilers with SIMT (Single Instruction Multiple Threads) execution models. In addition, they are also applicable to other types of processor or chip architectures such as CPU (Central Processing Unit) and GPGPU (General-Purpose computing on Graphics Processing Unit). The embodiments of the present invention do not impose specific limitations.

[0023] See Figure 1 The diagram shown is a flowchart of a compiler optimization method based on basic blocks according to an embodiment of the present invention. The method includes steps S11 to S13: Step S11: Obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; Step S12: Perform optimization operations on each basic block sequentially to obtain the optimized machine code function; wherein, for each basic block, the optimization operation includes: identifying the instructions to be optimized that belong to custom affine operations contained in the basic block, wherein the custom affine operations support at least two custom operation types; matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization result; Step S13: Output the optimized machine code function so that the hardware device executes the optimized machine code function.

[0024] Specifically, first, the machine code function to be optimized is obtained. This machine code function includes several basic blocks, each containing a series of instructions (machine code is the binary representation of these instructions). Then, optimization operations are performed on each basic block sequentially. After one basic block is optimized, the optimization operation continues for the next basic block until all basic blocks in the machine code function to be optimized have been optimized. This yields several optimized basic blocks, resulting in the optimized machine code function. Finally, the optimized machine code function is output so that the hardware device can execute it to implement its functionality.

[0025] When performing optimization operations on each basic block, the execution process is the same for each basic block. Taking any basic block (as the target basic block) as an example, the optimization operations for the target basic block include: identifying instructions belonging to custom affine operations from all instructions contained in the target basic block and designating them as instructions to be optimized (more than one instruction to be optimized), and custom affine operations support at least two custom operation types; for each identified instruction to be optimized, performing operation type matching and modifier matching according to a pre-set affine factor mapping table; performing affine constant folding optimization (chained instruction merging) on ​​successfully matched instructions to be optimized; and updating the affine factor mapping table according to the optimization results so that the next instruction to be optimized can perform operation type matching and modifier matching based on the updated affine factor mapping table, and so on, until all instructions to be optimized contained in the target basic block have completed the optimization operation.

[0026] Understandably, for instructions that are not to be optimized but are contained within the target basic block, there is no need to treat them as instructions to be optimized and perform optimization operations on them; the original instructions can be kept unchanged.

[0027] It should be noted that the embodiments of the present invention predefine a unified affine factor structure, and the corresponding custom affine operation supports at least two custom operation types. For example, various custom operation types and their corresponding instructions and combination formulas are shown in Table 1. In the combination formula, c1 and c2 represent affine constants (the constant offset in the affine expression reg=base+offset, which is also the immediate number that actually needs to be folded and merged).

[0028] Table 1 Custom Operation Types Understandably, an affine expression is a mathematical expression of the form reg=base+offset or reg=op(base,imm), where base is a variable and offset / imm are constants. During program execution, many address and index calculations have affine forms, and recognizing and propagating this type of information can optimize calculations.

[0029] As is understandable, an affine factor is a data structure in the compiler that describes the affine relationship between register values, base registers, and immediate values ​​(it is the program representation of affine expressions). It records that the value of a register can be represented as the result of a specific operation on the value of the base register. It is mainly used to track and propagate affine relationships. An affine factor contains four elements: operation type, base register, immediate value, and modifier. For example, the structure of an affine factor is shown in Table 2, and the corresponding semantic representation is: $value(r) = op(value(baseReg), imm), where op is determined by the opType field.

[0030] Table 2 Affine Factor Data Structure It should be noted that the embodiments of the present invention extend the concept of traditional affine expressions to support multiple operation types (such as addition, shift, multiplication, bitwise operations, etc. as shown in Table 1). Through the propagation and tracing of affine factors, the chained operation instructions in the basic block can be merged in the compiler to achieve an extended generalized affine constant folding optimization.

[0031] It should be noted that the embodiments of the present invention also pre-set an affine factor mapping table, which is used to store and maintain the mapping from registers to affine factors within the basic block, and provides interfaces for affine factor query, writing (insertion), and clearing (deletion), and is also used to manage the lifecycle of affine factors. It can be understood that since the optimization operations between each basic block are independent of each other (do not affect each other), before performing optimization operations on each basic block, it is necessary to initialize the affine factor mapping table to clear the current affine factor mapping table, so that there are no register mapping records corresponding to the basic block that has completed the previous optimization operation in the table, so as to avoid the optimization operation of the previous basic block from affecting the current basic block to be optimized.

[0032] It should be noted that, for the processing of Phi nodes, as a special instruction in the basic block, the registers defined cannot have affine factors (which would destroy the source affine factor), so they will not be identified as instructions to be optimized. The following processing rules can be set for them: (1) Treat Phi nodes as definitions of target registers; (2) Clear the affine factors defined by Phi nodes during the failure phase; (3) The results of Phi nodes cannot be represented in simple affine form.

[0033] It should be noted that, for the processing of cross-block definition scenarios, since the embodiments of the present invention only process local optimization within the same basic block and do not perform cross-basic block optimization operations, the following processing rules can be set for cross-block definition scenarios: (1) Registers defined in other basic blocks have no affine factor in this basic block; (2) Do not attempt to find affine factors across blocks; (3) Ensure the correctness of local optimization.

[0034] The compiler optimization method based on basic blocks provided in this invention supports affine propagation of multiple operation types through custom affine operations. By utilizing the propagation and tracing of affine factors within basic blocks, multiple chained operation instructions within a basic block are merged into a single instruction, significantly reducing the number of instructions and thus improving execution efficiency. At the same time, through strict operation type and modifier matching checks, the incompatibility between instructions with different operation types and different modifiers can be identified, thereby ensuring the correctness of the optimization.

[0035] In one optional embodiment, the instructions to be optimized that belong to the custom affine operation contained within the identification basic block specifically include: For each instruction contained within a basic block, the operation type of the instruction is identified based on the instruction's opcode; Determine whether an instruction belongs to a custom affine operation based on the operation type of the instruction and the custom operation types supported by the custom affine operation. When the operation type of an instruction is one of the custom operation types, the instruction is determined to be a custom affine operation, and the instruction that belongs to the custom affine operation is designated as an instruction to be optimized.

[0036] Specifically, in conjunction with the above embodiments, we will still use the target basic block as an example for explanation. When identifying the instructions to be optimized that belong to custom affine operations contained in the target basic block, the identification process is the same for each instruction contained in the target basic block. Here, we will take any instruction in the target basic block (as the target instruction) as an example. For the target instruction, we can first parse the opcode of the target instruction to identify the operation type corresponding to the target instruction based on the opcode of the target instruction. Then, we compare the operation type of the target instruction with the custom operation types supported by the custom affine operation to determine whether the target instruction belongs to the custom affine operation. When it is determined by comparison that the operation type of the target instruction is one of the custom operation types, the target instruction is determined to belong to the custom affine operation (the corresponding custom operation type enumeration value is returned), and the target instruction is taken as the instruction to be optimized.

[0037] For example, as shown in Table 1, after identifying all instructions within the basic block, the custom operation type enumeration values ​​are returned as shown in Table 3.

[0038] Table 3 Enumeration Values ​​for Custom Operation Types In one optional embodiment, the step of matching the operation type and modifier of the instruction to be optimized according to a preset affine factor mapping table specifically includes: For each instruction to be optimized, extract the source register and immediate value of the instruction; Determine whether the target affine factor corresponding to the source register of the instruction to be optimized exists in the preset affine factor mapping table; If it exists, then determine whether the operation type and modifier of the instruction to be optimized are the same as those of the target affine factor; If they are the same, then the instruction to be optimized is determined to be a successful match with the target affine factor.

[0039] Specifically, referring to the above embodiments, and still using the target basic block as an example, when performing operation type and modifier matching on the instructions to be optimized contained in the target basic block, the operation type and modifier matching process is the same for each instruction to be optimized contained in the target basic block. Here, we take any instruction to be optimized (as the target instruction to be optimized) as an example. For the target instruction to be optimized, we can first extract the source register and immediate value in the target instruction to be optimized, and then search the pre-set affine factor mapping table according to the source register in the target instruction to optimize to determine whether the target instruction to be optimized exists in the affine factor mapping table. The target affine factor corresponding to the source register of the target instruction to be optimized is determined. When the affine factor mapping table contains the target affine factor corresponding to the source register of the target instruction to be optimized, it is further determined whether the operation type of the target instruction to be optimized is the same as the operation type of the target affine factor, and whether the modifier of the target instruction to be optimized is the same as the modifier of the target affine factor. When the operation type and modifier of the target instruction to be optimized are all the same as the operation type and modifier of the target affine factor, it is determined that the target instruction to be optimized and the target affine factor are successfully matched. Then, affine constant folding optimization can be performed on the successfully matched target instruction to be optimized and the target affine factor.

[0040] For example, for a successfully matched target instruction to be optimized and a target affine factor, the following combination of conditions must be satisfied: $Compatible(fact, inst) fact.opType=inst.opType fact.modifiers=inst.modifiers, Here, fact refers to the source instruction of the target affine factor, and inst refers to the target instruction to be optimized. Conversely, by judging whether the target instruction to be optimized and the target affine factor meet the combination conditions, it can be determined whether the two are successfully matched.

[0041] It should be noted that operation type matching refers to a check mechanism that requires two instructions to have the same operation type when combining affine factors. The check logic is: fact.opType = inst.opType. Instructions with different operation types do not meet the mathematical simplification rules and must ensure that the operation types are consistent in order to be safely combined. For example, Table 1 defines 8 operation types. In the same basic block, only instructions with the same operation type can be affinely combined (the modifiers must also be the same) to ensure the correctness of the optimization.

[0042] For example: SSHL x,y,5 and SSHR z,x,3 are not equal to SSHR z,y,8; Only SSHL x,y,5 and SSHL z,x,3 can be combined to form SSHL z,y,8.

[0043] It should be noted that modifier matching refers to a check mechanism that requires two instructions to have the same modifier when combining affine factors. The check logic is: $fact.modifiers.s1Neg=inst.modifiers.s1Neg, fact.modifiers.s2Neg=inst.modifiers.s2Neg. Only by ensuring that the instruction modifiers (such as inverting the source operands) are consistent can the correctness of the optimization be ensured.

[0044] For example: SADD q32, 48, q31.n → fact[q32]={Add, q31, 48, mod=s2Neg} SADD q32, 0, q32 → Do not combine (modifier mismatch) In one optional embodiment, the step of performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization result, specifically includes: The matching instruction to be optimized and the target affine factor are combined and rewritten, and the position of the immediate value in the rewritten instruction is consistent with the position of the immediate value in the target affine factor in the source instruction. The target affine factor is cleared from the affine factor mapping table, and a new affine factor is generated according to the rewritten instructions and written into the affine factor mapping table.

[0045] Specifically, referring to the above embodiments, and still using the target instruction to be optimized as an example, when performing affine constant folding optimization on the successfully matched target instruction to be optimized and the target affine factor, instruction combination and instruction rewriting can be performed on the target instruction to be optimized and the target affine factor based on the operation type and immediate value of the target instruction to be optimized and the target affine factor, thereby obtaining the rewritten instruction; wherein, when performing instruction combination, the immediate value in the target instruction to be optimized and the immediate value in the target affine factor can be combined and calculated according to the combination formula corresponding to the operation type (as shown in Table 1), thereby obtaining the corresponding instruction. The new immediate value; when rewriting instructions, the instructions can be rewritten based on the new immediate value, and a slot-preserving rewriting strategy is adopted to ensure that the position of the new immediate value (i.e., the immediate value in the rewritten instruction) in the rewritten instruction is consistent with the position of the immediate value in the target affine factor in the source instruction corresponding to the target affine factor, so as to ensure that the position of the new immediate value in the instruction remains unchanged; then, the target affine factor is removed from the affine factor map table, and a new affine factor is generated according to the rewritten instruction and written into the affine factor map table.

[0046] It should be noted that the optimization operation for the instruction to be optimized can adopt a three-stage processing flow of "combination-failure-recording": (1) Combination stage: Check whether the current instruction to be optimized can be combined with the existing affine factors in the affine factor mapping table. If so, execute instruction combination and instruction rewriting. (2) Failure phase: Remove the affine factors associated with the registers defined by the currently optimized instruction from the affine factor mapping table; (3) Recording phase: Create a new affine factor for the current instruction and write it into the affine factor mapping table.

[0047] For example, suppose the previous instruction after combination and rewriting is: SADD x, y, 5, which generates the affine factor of x as: x → {Add, y, 5, no modifier}, and writes it into the affine factor map table; if the current instruction to be optimized is: SADD z, x, 3, then its source register x is extracted, and the affine factor map table is queried according to the source register x. If the table finds that the affine factor corresponding to x exists, operation type matching and modifier matching are performed. If the matching is successful, instruction combination and instruction rewriting are executed, and the instruction SADD z, x, 3 is rewritten as: SADD z, y, 8. The affine factor of x is removed from the affine factor map table, and the affine factor of z is generated according to the rewritten instruction as: z → {Add, y, 8, no modifier}, and written into the affine factor map table.

[0048] It should be noted that slot retention is a rewriting strategy that keeps operands in their original positions during instruction rewriting. Instruction operands have fixed positions (for example, in the SADD dst, src1, src2 instruction, src1 and src2 each have their own dedicated positions). By adopting the slot retention rewriting strategy, this embodiment of the invention can record the original slot positions of immediate values ​​in the source instruction during instruction rewriting and ensure that the rewritten immediate values ​​remain in the same positions before and after the rewriting, thereby minimizing instruction modification.

[0049] The rules for the slot reservation and rewriting strategy are as follows: If the immediate value is in the src1 position, the immediate value will remain in the src1 position after rewriting; If the immediate value is at position src2, the immediate value will remain at position src2 after rewriting.

[0050] The following is an example of slot reservation: SADD x, 1, y → fact[x] = {Add, y, 1} (The immediate value in the source instruction is in src1) SADD z, x, 3 → rewritten as SADD z, 4, y (immediate values ​​remain in src1, consistent with the source instruction). It should be noted that the operand positions in shift operations have special semantics. Taking the instruction SSHL dst, src1, src2 as an example, this instruction means dst = src1 << src2. The rules for setting it are as follows: Only the mode where src1 = register and src2 = immediate value is supported; The mode where src1 = immediate value and src2 = register is not supported.

[0051] In one optional embodiment, prior to performing affine constant folding optimization on the successfully matched instructions to be optimized, the method further includes: Perform boundary overflow checks on the immediate values ​​of the matched instructions to be optimized and the target affine factor; If the check passes, the matching instructions to be optimized are optimized by affine constant folding, and the affine factor mapping table is updated according to the optimization results. If the check fails, the affine constant folding optimization is not performed on the successfully matched instructions to be optimized. Instead, a new affine factor is generated based on the successfully matched instructions to be optimized and written into the affine factor mapping table.

[0052] Specifically, referring to the above embodiments, we will still use the target instruction to be optimized as an example. Before performing affine constant folding optimization on the successfully matched target instruction to be optimized and the target affine factor, overflow protection is required. That is, boundary overflow checks are performed on the immediate values ​​in the successfully matched target instruction to be optimized and the immediate values ​​in the target affine factor to determine whether the immediate values ​​overflow. Only when the check passes (meaning there is no overflow boundary) can we continue to perform affine constant folding optimization on the successfully matched target instruction to be optimized and the target affine factor, and update the affine factor mapping table according to the optimization results (the specific execution process is the same as in the above embodiments, and will not be repeated here). When the check fails (meaning there is an overflow boundary), we do not perform affine constant folding optimization on the successfully matched target instruction to be optimized and the target affine factor, and update the affine factor mapping table according to the optimization results. Instead, we keep the target instruction to be optimized unchanged, and generate a new affine factor according to the target instruction to be optimized and write it into the affine factor mapping table.

[0053] It should be noted that, for the eight custom operation types shown in Table 1, boundary overflow checks are required for addition, shift, and multiplication operations, while bitwise operations do not overflow and therefore do not require additional checks.

[0054] It should be noted that the combination formulas for different operation types are as follows: Addition operation: $c_new = c1 + c2 Check for overflow conditions: $(c2>0 c1>INT64_MAX-c2) (c2<0 c1<INT64_MIN-c2) Shift operation: $c_new = c1 + c2 Check boundary conditions: $0≤c1≤63 0≤c2≤63 c1+ c2≤63 Multiplication operation: $c_new = c1 × c2 Check for overflow conditions: Use compiler built-in functions (such as _builtin_mul_overflow) to check for multiplication overflow.

[0055] For example, regarding addition overflow checks: if (c2 > 0 && c1 > INT64_MAX - c2) → overflow (exceeds the maximum value that a 64-bit register can hold); if (c2 < 0 && c1 < INT64_MIN - c2) → underflow (exceeds the maximum value that a 64-bit register can hold).

[0056] For example, regarding shift boundary checks: if (c1 < 0 || c2 < 0) → invalid if (c1>63 || c2>63) → Out of bounds if (c1 + c2 > 63) → the combination will result in an out-of-bounds error. In one alternative embodiment, the method further includes: When there is no target affine factor corresponding to the source register of the instruction to be optimized in the affine factor mapping table, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table; When the operation type of the instruction to be optimized is different from that of the target affine factor, or / and the modifier of the instruction to be optimized is different from that of the target affine factor, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table.

[0057] Specifically, referring to the above embodiments, and still using the target instruction to be optimized as an example, after determining whether the affine factor corresponding to the source register of the target instruction to be optimized exists in the affine factor mapping table, if it is determined that the target affine factor corresponding to the source register of the target instruction to be optimized does not exist in the affine factor mapping table, then the "affine constant folding optimization of the successfully matched target instruction to be optimized and the target affine factor, and updating the affine factor mapping table according to the optimization result" is not performed. Instead, the target instruction to be optimized remains unchanged, and a new affine factor is generated according to the target instruction to be optimized and written into the affine factor mapping table; similarly, if it is determined that the source register of the target instruction to be optimized exists in the affine factor mapping table, then the "affine constant folding optimization of the successfully matched target instruction to be optimized and the target affine factor corresponding to the source register of the target instruction to be optimized" is not performed. The target affine factor is determined, and it is further determined whether the operation type of the target instruction to be optimized is the same as the operation type of the target affine factor, and whether the modifier of the target instruction to be optimized is the same as the modifier of the target affine factor. If it is determined that the operation type of the target instruction to be optimized is not the same as the operation type of the target affine factor, or / and the modifier of the target instruction to be optimized is not the same as the modifier of the target affine factor, then the "affine constant folding optimization is performed on the successfully matched target instruction to be optimized and the target affine factor, and the affine factor mapping table is updated according to the optimization result" is not executed. Instead, the target instruction to be optimized remains unchanged, and a new affine factor is generated according to the target instruction to be optimized and written into the affine factor mapping table.

[0058] In one alternative embodiment, the method further includes, before writing the new affine factor into the affine factor mapping table: Determine whether the new affine factor is a self-dependent instruction; If it belongs to the category, the new affine factor will not be written into the affine factor mapping table; If it does not belong to the affine factor, then the new affine factor is written into the affine factor mapping table.

[0059] Specifically, in conjunction with the above embodiments, for the scenarios where new affine factors are generated and written into the affine factor mapping table, in order to avoid the propagation of erroneous affine factors caused by self-dependent instructions, self-dependency detection is required. That is, before writing the new affine factor into the affine factor mapping table, it is necessary to determine whether the new affine factor belongs to a self-dependent instruction. If it is determined that the new affine factor belongs to a self-dependent instruction, the "writing the new affine factor into the affine factor mapping table" will not be executed. Only when it is determined that the new affine factor does not belong to a self-dependent instruction will the new affine factor be written into the affine factor mapping table.

[0060] It should be noted that the detection logic of self-dependency detection is as follows: $dstReg=srcReg. For self-dependent instructions, if they are instructions to be optimized and the operation type and modifier match successfully, instruction combination and instruction rewriting can be performed on the self-dependent instructions. However, the new affine factor generated based on the rewritten instructions will not be written into the affine factor mapping table (there is no need to generate a new affine factor based on the rewritten instructions).

[0061] For example, for the self-dependent instruction SADD q1, q1, 4, it is possible to combine, but the affine factor fact[q1] of the self-dependent instruction is not recorded.

[0062] See Figure 2 The diagram shown is an optimization flowchart of a basic block in a compiler optimization method based on basic blocks according to an embodiment of the present invention. The optimization operation flow of a certain basic block will be described below in conjunction with all the above embodiments: S21. Initialize the affine factor mapping table; S22. Read the next instruction in the basic block; S23. Determine whether the current instruction is a custom affine operation. If yes, execute S24; otherwise, execute S33. S24. Retrieve the source register and immediate value of the current instruction; S25. Determine whether the source register of the current instruction has an affine factor in the affine factor mapping table. If yes, execute S26; otherwise, execute S30. S26. Determine whether the operation type of the current instruction matches the operation type of the affine factor. If yes, execute S27; otherwise, execute S30. S27. Determine whether the modifier of the current instruction matches the modifier of the affine factor. If yes, execute S28; otherwise, execute S30. S28. Determine whether the boundary overflow check of the current instruction and affine factor has passed. If yes (meaning no overflow), then execute S29; otherwise, execute S30. S29. Perform instruction combination and instruction rewriting on the current instruction and affine factor; S30, Failure handling: Clear the affine factors associated with the registers defined by the current instruction from the affine factor map table; S31. Create a new affine factor for the current instruction and determine whether the new affine factor passes the self-dependency check. If it does (meaning it is a self-dependent instruction), then execute S33; otherwise, execute S32. S32. Record the new affine factor in the affine factor mapping table; S33. Determine if there are any unread instructions in the basic block. If yes, return to S22; otherwise, end the optimization operation on the basic block.

[0063] For example, the addition chain is optimized as follows: Before optimization: SADD x, y, 5 → fact[x]={Add, y, 5} SADD z, x, 3 → Detected fact[x], combined After optimization: SADD z, y, 8 → Immediate values ​​are combined into 5 + 3 = 8 For example, the shift chain is optimized as follows: Before optimization: SSHL x,y,5 → fact[x]={ShiftLeft,y,5} SSHL z, x, 3 → detected fact[x], combination After optimization: SSHL z, y, 8 → Shift values ​​combined to 5 + 3 = 8 For example, the bitwise operation chain can be optimized as follows: Before optimization: SAND x, y, 0xFF → fact[x]={And, y, 0xFF} SAND z, x, 0x0F → Detected fact[x], combination After optimization: SAND z, y, 0x0F → Immediate values ​​are merged into 0xFF & 0x0F = 0x0F This invention also provides a basic block-based compiler optimization system for implementing the basic block-based compiler optimization method described in any of the above embodiments. See [link to relevant documentation]. Figure 3 The diagram shown is a structural block diagram of a compiler optimization system based on basic blocks according to an embodiment of the present invention. The system includes: Input module 11 is used to obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; The optimization module 12 is used to sequentially perform optimization operations on each basic block to obtain optimized machine code functions. For each basic block, the optimization operation includes: identifying instructions within the basic block that belong to custom affine operations, wherein the custom affine operations support at least two custom operation types; matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions to be optimized; and updating the affine factor mapping table based on the optimization results. Output module 13 is used to output the optimized machine code function so that the hardware device executes the optimized machine code function.

[0064] Preferably, the optimization module 12 identifies the instructions to be optimized that belong to a custom affine operation contained within the basic block, specifically including: For each instruction contained within a basic block, the operation type of the instruction is identified based on the instruction's opcode; Determine whether an instruction belongs to a custom affine operation based on the operation type of the instruction and the custom operation types supported by the custom affine operation. When the operation type of an instruction is one of the custom operation types, the instruction is determined to be a custom affine operation, and the instruction that belongs to the custom affine operation is designated as an instruction to be optimized.

[0065] Preferably, the optimization module 12 performs operation type and modifier matching on the instruction to be optimized according to a preset affine factor mapping table, specifically including: For each instruction to be optimized, extract the source register and immediate value of the instruction; Determine whether the target affine factor corresponding to the source register of the instruction to be optimized exists in the preset affine factor mapping table; If it exists, then determine whether the operation type and modifier of the instruction to be optimized are the same as those of the target affine factor; If they are the same, then the instruction to be optimized is determined to be a successful match with the target affine factor.

[0066] Preferably, the optimization module 12 performs affine constant folding optimization on the successfully matched instructions to be optimized, and updates the affine factor mapping table according to the optimization results, specifically including: The matching instruction to be optimized and the target affine factor are combined and rewritten, and the position of the immediate value in the rewritten instruction is consistent with the position of the immediate value in the target affine factor in the source instruction. The target affine factor is cleared from the affine factor mapping table, and a new affine factor is generated according to the rewritten instructions and written into the affine factor mapping table.

[0067] Preferably, before the optimization module 12 performs affine constant folding optimization on the successfully matched instructions to be optimized, it is further used to: Perform boundary overflow checks on the immediate values ​​of the matched instructions to be optimized and the target affine factor; If the check passes, the matching instructions to be optimized are optimized by affine constant folding, and the affine factor mapping table is updated according to the optimization results. If the check fails, the affine constant folding optimization is not performed on the successfully matched instructions to be optimized. Instead, a new affine factor is generated based on the successfully matched instructions to be optimized and written into the affine factor mapping table.

[0068] Preferably, the optimization module 12 is further configured to: When there is no target affine factor corresponding to the source register of the instruction to be optimized in the affine factor mapping table, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table; When the operation type of the instruction to be optimized is different from that of the target affine factor, or / and the modifier of the instruction to be optimized is different from that of the target affine factor, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table.

[0069] Preferably, before the optimization module 12 writes the new affine factor into the affine factor mapping table, it is further used to: Determine whether the new affine factor is a self-dependent instruction; If it belongs to the category, the new affine factor will not be written into the affine factor mapping table; If it does not belong to the affine factor, then the new affine factor is written into the affine factor mapping table.

[0070] Combination Figure 4 The diagram shown is a structural block diagram of a compiler optimization system based on basic blocks according to another embodiment of the present invention. The entire system includes an input module, an optimization module, and an output module, wherein: The input module is used to receive the machine code function to be optimized; The optimization module includes an analysis unit, an optimization processing unit, and a safety check unit. The analysis unit further includes an operation type identifier, an operand extractor, and an affine factor manager, used to identify the operation type of an instruction, extract the operands of the instruction, and maintain the affine factor mapping table of the basic blocks. The optimization processing unit includes a combination processor, a failure processor, and an affine factor recorder, used to perform the three-stage processing flow of combination, failure, and recording. The safety check unit includes operation type matching checks, modifier matching checks, overflow protection checks, and self-dependency detection, used to implement multiple safety checks to ensure the correctness and safety of the optimization. The output module is used to output the optimized machine code function so that the hardware device executes the optimized machine code function.

[0071] It should be noted that the basic block-based compiler optimization system provided in this embodiment of the invention can implement all the processes of the basic block-based compiler optimization method described in any of the above embodiments. The functions and technical effects of each module and unit in the system are the same as those of the basic block-based compiler optimization method described in the above embodiments, and will not be repeated here.

[0072] This invention also provides a computer-readable storage medium including a stored computer program, which, when running, controls the device where the computer-readable storage medium is located to execute the basic block-based compiler optimization method described in any of the above embodiments.

[0073] This invention also provides a terminal device, see [link to relevant documentation]. Figure 5 The diagram shown is a structural block diagram of a terminal device according to an embodiment of the present invention. The terminal device includes a processor 10, a memory 20, and a computer program stored in the memory 20 and configured to be executed by the processor 10. When the processor 10 executes the computer program, it implements the basic block-based compiler optimization method described in any of the above embodiments.

[0074] Preferably, the computer program can be divided into one or more modules / units (such as computer program 1, computer program 2, ...), and the one or more modules / units are stored in the memory 20 and executed by the processor 10 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the computer program in the terminal device.

[0075] The processor 10 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor 10 may be any conventional processor. The processor 10 is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0076] The memory 20 mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., while the data storage area can store related data, etc. Furthermore, the memory 20 can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard drive, a smart media card (SMC), a secure digital card (SD), and a flash card, or other volatile solid-state storage devices.

[0077] It should be noted that the aforementioned terminal devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art. Figure 5 The structural block diagram shown is merely a structural example of the terminal device described above and does not constitute a limitation on the structure of the terminal device. The terminal device may include more or fewer components than shown, or combine certain components, or use different components.

[0078] In summary, the compiler optimization method, system, computer-readable storage medium, and terminal device based on basic blocks provided by the embodiments of the present invention have the following beneficial effects: (1) Advantages of optimization effect (1.1) Support for multiple operation types: Supports affine propagation of 8 operation types, covering common operations such as GPU; (1.2) Chain merging: Merging multiple chained instructions into a single instruction, significantly reducing the number of instructions and improving operating efficiency; (1.3) Slot reservation: Keep the immediate value position unchanged and minimize instruction modifications; (2) Security advantages (2.1) Operation type isolation: Instructions of different operation types cannot be combined to avoid semantic errors; (2.2) Modifier check: Ensure modifier matching to guarantee the correctness of optimization; (2.3) Boundary overflow protection: Comprehensive overflow detection to avoid numerical errors; (2.4) Self-dependency detection: Correctly handle self-dependent instructions to prevent error propagation; (3) Realizing advantages (3.1) Unified framework: A single pass handles all operation types, resulting in concise code; (3.2) Local optimization: Processing within the same basic block, without the need for complex data flow analysis; (3.3) Scalability: Supports the addition of new operation types, making implementation easier; (4) Performance advantages (4.1) Single pass scan: Each basic block requires only one forward scan; (4.2) Low time complexity: O(n) complexity, where n is the number of instructions in a basic block; (4.3) Low space overhead: Only a mapping table from registers to affine factors needs to be maintained.

[0079] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A compiler optimization method based on basic blocks, characterized in that, include: Obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; Optimization operations are performed sequentially on each basic block to obtain optimized machine code functions. For each basic block, the optimization operation includes: identifying instructions to be optimized that belong to custom affine operations within the basic block, wherein the custom affine operations support at least two custom operation types; matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization results. The optimized machine code function is output so that the hardware device executes the optimized machine code function.

2. The compiler optimization method based on basic blocks as described in claim 1, characterized in that, The instructions to be optimized that belong to the custom affine operation contained in the basic recognition block specifically include: For each instruction contained within a basic block, the operation type of the instruction is identified based on the instruction's opcode; Determine whether an instruction belongs to a custom affine operation based on the operation type of the instruction and the custom operation types supported by the custom affine operation. When the operation type of an instruction is one of the custom operation types, the instruction is determined to be a custom affine operation, and the instruction that belongs to the custom affine operation is designated as an instruction to be optimized.

3. The compiler optimization method based on basic blocks as described in claim 1, characterized in that, The step of matching the operation type and modifier of the instruction to be optimized according to the preset affine factor mapping table specifically includes: For each instruction to be optimized, extract the source register and immediate value of the instruction; Determine whether the target affine factor corresponding to the source register of the instruction to be optimized exists in the preset affine factor mapping table; If it exists, then determine whether the operation type and modifier of the instruction to be optimized are the same as those of the target affine factor; If they are the same, then the instruction to be optimized is determined to be a successful match with the target affine factor.

4. The compiler optimization method based on basic blocks as described in claim 3, characterized in that, The step of performing affine constant folding optimization on the successfully matched instructions to be optimized, and updating the affine factor mapping table according to the optimization results, specifically includes: The matching instruction to be optimized and the target affine factor are combined and rewritten, and the position of the immediate value in the rewritten instruction is consistent with the position of the immediate value in the target affine factor in the source instruction. The target affine factor is cleared from the affine factor mapping table, and a new affine factor is generated according to the rewritten instructions and written into the affine factor mapping table.

5. The compiler optimization method based on basic blocks as described in claim 3, characterized in that, Before performing affine constant folding optimization on the successfully matched instructions to be optimized, the method further includes: Perform boundary overflow checks on the immediate values ​​of the matched instructions to be optimized and the target affine factor; If the check passes, the matching instructions to be optimized are optimized by affine constant folding, and the affine factor mapping table is updated according to the optimization results. If the check fails, the affine constant folding optimization is not performed on the successfully matched instructions to be optimized. Instead, a new affine factor is generated based on the successfully matched instructions to be optimized and written into the affine factor mapping table.

6. The compiler optimization method based on basic blocks as described in claim 3, characterized in that, The method further includes: When there is no target affine factor corresponding to the source register of the instruction to be optimized in the affine factor mapping table, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table; When the operation type of the instruction to be optimized is different from that of the target affine factor, or / and the modifier of the instruction to be optimized is different from that of the target affine factor, a new affine factor is generated according to the instruction to be optimized and written into the affine factor mapping table.

7. The compiler optimization method based on basic blocks as described in any one of claims 4 to 6, characterized in that, Before writing the new affine factor into the affine factor mapping table, the method further includes: Determine whether the new affine factor is a self-dependent instruction; If it belongs to the category, the new affine factor will not be written into the affine factor mapping table; If it does not belong to the affine factor, then the new affine factor is written into the affine factor mapping table.

8. A compiler optimization system based on basic blocks, characterized in that, include: The input module is used to obtain the machine code function to be optimized, wherein the machine code function includes several basic blocks; An optimization module is used to sequentially perform optimization operations on each basic block to obtain optimized machine code functions. For each basic block, the optimization operation includes: identifying instructions within the basic block that belong to custom affine operations (the custom affine operations support at least two custom operation types); matching the operation type and modifier of the instructions to be optimized according to a preset affine factor mapping table; performing affine constant folding optimization on the successfully matched instructions; and updating the affine factor mapping table based on the optimization results. The output module is used to output the optimized machine code function so that the hardware device executes the optimized machine code function.

9. A computer-readable storage medium, characterized in that, The computer program includes a stored computer program that, when running, controls the device containing the computer-readable storage medium to perform a compiler optimization method based on basic blocks as described in any one of claims 1 to 7.

10. A terminal device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the block-based compiler optimization method as described in any one of claims 1 to 7.

Images