Dynamic management method and system for RISC-V vector register pressure

Abstract

The application discloses a kind of dynamic management methods and systems for RISC-V vector register pressure, it is related to computer processor architecture and compiler optimization technical field, including: in the process of program compilation or execution, the use state of RISC-V vector register is monitored in real time, when monitoring that vector register pressure is over limit, target register is selected and management strategy is triggered;Identify the source instruction of vector value in target register, and execute heavy materialization effectiveness verification, according to the verification result, vector value is divided into two categories of materializable and non-materializable;According to the division result, dynamically estimate the cost of heavy materialization and register overflow cost;Compare two kinds of costs, if heavy materialization cost is higher, then decision adopts register overflow strategy and executes;If register overflow cost is higher, then decision adopts heavy materialization strategy and executes.The application can improve the computing performance of processor, solve the performance loss problem caused by high register pressure.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer processor architecture and compiler optimization technology, and particularly relates to a dynamic management method and system for RISC-V vector register pressure. BACKGROUND

[0002] The statements in this section merely provide background information related to the present application and do not necessarily constitute the prior art.

[0003] With the rapid development of artificial intelligence (AI), machine learning (ML) and high-performance computing (HPC) applications, the demand for processor parallel computing capability is increasing, and vector processing or single instruction multiple data stream (SIMD) is one of the key technologies to meet this demand. Among them, RISC-V (Reduced Instruction Set Computer, Fifth Edition) as an open and extensible instruction set architecture, RISC-V Vector Extension Specification (RVV) provides a flexible and powerful vector processing instruction set, RVV not only defines the vector length (VLEN) of the vector register, but also introduces the vector length multiplier (lmul) to allow multiple physical vector registers to be combined into a longer vector logical register group, such as when V0-V3 four vector registers can be regarded as a single logical register. RVV is widely used due to this flexible vector register configuration feature. However, when executing compute-intensive kernel functions in AI or HPC, such as general matrix multiplication (GEMM) or convolution, although the high lmul configuration can improve the computing throughput, it will sharply reduce the number of available logical vector registers, causing high vector register pressure.

[0004] ​​​​In the prior art, the compiler usually adopts a register overflow strategy to deal with high register pressure, that is, when there are not enough registers to store the necessary intermediate values, the compiler will generate additional instructions to store the contents of a certain vector register into the main memory and reload it back into the vector register when needed later. However, the amount of data in the RVV vector register is determined by vlen and lmul, and under high lmul configuration, the next overflow operation needs to access a large amount of data, which will bring extremely high memory I / O overhead, seriously offsetting the performance gain of high lmul. Although there is also a re-materialization technology in the existing compiler technology, that is, the value is recalculated when needed instead of being loaded from memory, but the traditional re-materialization is mostly applied in a static heuristic way in the general scalar register scenario, which is difficult to adapt to the dynamic characteristics of the RVV vector architecture, cannot be applied in complex instructions, cross basic block data flow and involve special hardware states (such as vtype, mask register state, Vta / Vma strategy bit in RVV, etc.), and this static materialization mechanism does not have the dynamic decision-making ability for high register pressure scenarios, so the application of this technology by the existing compiler (usually a static AOT compiler) is very limited. Therefore, the existing technology cannot effectively determine which strategy to choose between the register overflow strategy and the re-materialization strategy, and cannot effectively adapt to the high lmul configuration requirement of the RVV architecture. SUMMARY

[0005] To solve the problem of high vector register pressure faced by the RISC-V vector processor in the prior art under high lmul configuration, the present application provides a dynamic management method and system for RISC-V vector register pressure, which monitors the vector register pressure, analyzes the calculation source and re-calculation feasibility of the vector value in the target register, dynamically estimates the re-materialization cost and register overflow cost and compares them, selects the strategy with lower cost for execution, and replaces expensive memory access with cheap re-calculation, significantly improving the computing performance of the RVV processor under high lmul configuration, and effectively solving the performance loss problem caused by high register pressure.

[0006] In a first aspect, the present application provides a dynamic management method for RISC-V vector register pressure.

[0007] A dynamic management method for RISC-V vector register pressure, comprising:

[0008] During program compilation or execution, the usage state of the RISC-V vector register is monitored in real time, and when the vector register pressure is monitored to be out of limit, a target register is selected and a management strategy is triggered;

[0009] The source instruction of the vector value in the target register is identified, and a heavy materialization validity verification is performed, and the vector value is divided into two categories of re-materializable and non-re-materializable according to the verification result;

[0010] According to the division result, the heavy materialization cost and the register overflow cost are dynamically estimated;

[0011] The two types of costs are compared, if the heavy materialization cost is higher, the register overflow strategy is decided to be adopted and executed, if the register overflow cost is higher, the heavy materialization strategy is decided to be adopted and executed.

[0012] Further technical solutions, the heavy materialization validity verification comprises:

[0013] The operand activity check is to confirm that the input operand required by the source instruction remains valid and is not redefined at the future re-insertion point;

[0014] The context consistency check confirms that the vector environment required by the source instruction execution is consistent with the re-insertion point;

[0015] The side effect and safety check confirms that the source instruction does not involve non-deterministic operation, has no side effect, and does not involve a modifiable memory area.

[0016] Further technical solutions, according to the verification result, the vector value is divided into two categories of re-materializable and non-re-materializable, comprising:

[0017] When the source instruction calculation overhead of the vector value is lower than the set value, and the heavy materialization validity verification is passed, or the environment is inconsistent and can be restored by a low-overhead instruction, the vector value is divided into a re-materializable vector value;

[0018] When the original instruction calculation overhead of the vector value is higher than the set value, or the heavy materialization validity verification is not passed, the vector value is divided into a non-re-materializable vector value.

[0019] Further technical solutions, the register overflow cost includes the instruction overhead and the memory access delay overhead of the vector storage instruction and the subsequent vector loading instruction;

[0020] The register overflow cost The estimation formula is:

[0021] ;

[0022] In the above formula, is the overhead of the vector storage instruction, is the overhead of the subsequent vector loading instruction, is the overhead of the memory access delay.

[0023] Further technical solutions, the calculation of the heavy materialization cost comprises:

[0024] If the vector value in the target register is not re-materializable, the re-materialization cost is infinite;

[0025] If the vector value in the target register is re-materializable, the re-materialization cost includes the overhead of re-executing the source instruction and the additional overhead required to meet consistency; wherein the additional overhead includes: environment recovery overhead, scalar operand reload overhead.

[0026] Further technical solutions, using register overflow strategy and execution, are to generate a storage instruction to store the vector value in the target register into memory, and generate a load instruction at the subsequent use point to recover the vector value;

[0027] Using the re-materialization strategy and execution, the storage instruction of the target register is not generated, and the register allocator is instructed to overwrite the target register, and when the vector value in the target register is needed at the subsequent use point, the necessary environment recovery code is generated and the source instruction is re-inserted to calculate the vector value.

[0028] In a second aspect, the present application provides a dynamic management system for RISC-V vector register pressure.

[0029] A dynamic management system for RISC-V vector register pressure, comprising:

[0030] A register pressure monitoring module for monitoring the usage state of RISC-V vector registers in real time during program compilation or execution, and selecting a target register and triggering a management strategy when the vector register pressure is out of limit;

[0031] A vector value analysis and verification module for identifying the source instruction of the vector value in the target register and performing re-materialization effectiveness verification, and dividing the vector value into two categories of re-materializable and non-re-materializable according to the verification result;

[0032] A dynamic cost evaluation module for dynamically evaluating the re-materialization cost and register overflow cost according to the division result;

[0033] A decision and code generation module for comparing the costs of the two categories, and if the re-materialization cost is higher, the register overflow strategy and execution are adopted; if the register overflow cost is higher, the re-materialization strategy and execution are adopted.

[0034] In a third aspect, the present application further provides an electronic device, comprising: a memory for storing executable instructions; a processor for executing the executable instructions stored in the memory to implement the above-mentioned dynamic management method for RISC-V vector register pressure.

[0035] In a fourth aspect, the present application also provides a computer readable storage medium storing executable instructions for causing a processor to implement the above-mentioned dynamic management method for RISC-V vector register pressure when the processor executes the executable instructions.

[0036] In a fifth aspect, the present application also provides a computer program product comprising executable instructions stored in a computer readable storage medium, wherein a processor of an electronic device reads the executable instructions from the computer readable storage medium and executes the executable instructions to implement the above-mentioned dynamic management method for RISC-V vector register pressure.

[0037] The above one or more technical solutions have the following beneficial effects:

[0038] 1. The present application proposes a dynamic management method and system for RISC-V vector register pressure, which monitors the pressure state of the vector register in real time, analyzes the calculation source of the vector value in the target register when the vector register pressure needs to be released, dynamically estimates the materialization cost and register overflow cost , and compares the costs to determine and decide, such as deciding to use the materialization strategy, i.e., re-inserting the source instruction to recover the value at the subsequent use point, or deciding and executing the traditional register overflow strategy, which significantly improves the computing performance of the RISC-V vector (RVV) processor under high configuration by replacing expensive memory access with cheap recalculation.

[0039] 2. The present application establishes a dynamic cost model, uses cheap recalculation instead of expensive memory I / O when the materialization cost is lower than the overflow cost, which greatly avoids the huge performance delay caused by register overflow, significantly improves the execution efficiency of the program on the RISC-V vector processor, and effectively improves the performance; under the side effect of high configuration, the compiler runtime can more confidently select the optimal high configuration for AI and HPC loads, thereby fully exploiting the computing potential of the RVV architecture; the dynamic cost-based decision mechanism can adapt to different hardware platforms (different memory delays) and different computing tasks (different recalculation costs), and implement the optimal register management strategy, which is adaptive.

[0040] ​Advantages of the additional aspects of the application will become apparent in the following description, which is given by way of example only, from the description that follows, or can be learned from practice of the application. BRIEF DESCRIPTION OF DRAWINGS

[0041] The accompanying drawings, which form a part of this specification, are included to provide a further understanding of the application, and are incorporated by reference in their entirety.

[0042] Figure 1 The overall flow chart of the dynamic management method for RISC-V vector register pressure according to the embodiments of the application is shown in the figure;

[0043] Figure 2 The structure schematic diagram of the dynamic management system for RISC-V vector register pressure according to the embodiments of the application is shown in the figure. DETAILED DESCRIPTION

[0044] It should be noted that the following detailed description is merely exemplary, and is intended to provide further description of the application, and is not intended to limit the exemplary embodiments according to the application. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they mean that there is a feature, step, operation, device, component and / or combination thereof.

[0045] TERMINOLOGY

[0046] RVV: RISC-V Vector Extension, RISC-V Vector Extension Specification.

[0047] vlen: Vector Register Length (bits), such as 128 / 256 / 512.

[0048] lmul: Vector Length Multiplier, which determines the number of physical registers occupied by the logical register group.

[0049] vtype: Type register containing vector configuration such as element width (sew), vector length multiplier (lmul), etc.

[0050] Vta / vma: Tail Agnostic / Mask Agnostic, policy flag.

[0051] Register pressure: In a given code interval, the tension measure of the number of active values required registers and the number of available registers.

[0052] Register spill: write register value back to memory (usually stack) and load later.

[0053] Heavy materialization: recalculate a value at usage point instead of loading from memory.

[0054] Class A value / Class B value: cheaply materializable vector value / non- or un- materializable vector value.

[0055] JIT: Just-In-Time Compiler, which dynamically compiles intermediate code or bytecode into machine code during program execution. JIT compiler usually has more execution information at runtime, so it can make more accurate optimization decisions.

[0056] AOT: Ahead-of-Time Compiler, which directly compiles source code into target machine code by compiler before program execution, without the need for compilation in the running phase. AOT compilation usually has the characteristics of sufficient compilation time and stable optimization.

[0057] vsetvli: vector configuration instruction in RISC-V vector extension (RVV), used to set the effective length of vector register vl and vector type register vtype according to the given parameters; vtype contains element width (sew), vector length multiplier (lmul) and Vta / Vma vector environment configuration. Execute vsetvli instruction to restore or switch vector execution environment, so that subsequent vector instructions are executed under the expected vector configuration.

[0058] IR: Intermediate Representation, an abstract representation of program structure used by compiler internally, which can be compared to the "internal language" of the compiler. IR can facilitate compiler optimization, data flow analysis, register allocation and other operations.

[0059] SSA: Static Single Assignment, a form of IR representation, in which each variable has only one definition, and each assignment must produce a new variable name. SSA form can significantly simplify the data flow analysis of the compiler, and is the mainstream representation of current compilers.

[0060] Def-Use Chain: Definition-Use Chain, an important structure in compiler data flow analysis, used to describe the relationship between a value (variable or register) and all its "use points" in the program. Through the Def-Use chain, the compiler can quickly track the source of a register or intermediate value, which is used for re-materialization judgment, live interval analysis, etc.

[0061] CFG: Control Flow Graph, a directed graph used to describe the transfer relationship between basic blocks of a program, used for control flow analysis by the compiler.

[0062] DAG: Data Flow Graph, a graph structure used to represent the internal data dependency relationship of a program, used to track operation chains and build re-materialization chains.

[0063] Latency: Instruction latency, refers to the number of cycles required for an instruction to be issued and produce results.

[0064] VL / VLmul: Vector Length / Vector Length Multiplier, a key parameter in RVV used to determine the visible length of vector registers.

[0065] Embodiment One

[0066] As pointed out in the background art, currently on RISC-V vector (RVV) processors, especially when using high configurations, although high values allow a single vector instruction to process more data elements, thereby more effectively distributing the overhead of instruction fetching and decoding, helping to hide the execution latency of the calculation unit and improve the calculation throughput, but high lmul values drastically reduce the number of independent logical vector registers available to the compiler. For example, a RISC-V processor with 32 physical vector registers (V0-V31) can use 32 independent logical registers when , but when , the number of available independent logical registers is reduced to 4. Since the compiler needs a large number of registers to store intermediate values, accumulators, loop variables, and memory addresses when compiling complex calculation kernel functions, when the number of available logical vector registers is too small, it will cause high vector register pressure. Existing technologies mainly use register spilling strategies to cope with it, i.e. storing the contents of the vector register into memory, however, since the vector register of RVV can be very long (the length is jointly determined by and ), such spilling operations will cause extremely high overhead memory I / O, which will seriously offset the performance advantages brought by high .

[0067] In addition, the existing heavy materialization technology in the static compiler has limited application: on the one hand, traditional heavy materialization is usually applied in a static heuristic manner in the general scalar register scenario, and the cost model usually assumes that the instruction execution delay and the memory access delay are relatively stable, but in the RVV vector architecture, the vector length vlen, the lmul configuration and the actual runtime memory hierarchy (cache hit rate, bandwidth, etc.) can significantly affect the real overhead of one overflow or one recalculation, and it is difficult to accurately characterize the real overhead by simply relying on the static estimation of the compiler In relation to The size of the compiler often adopts a conservative strategy to reduce the frequency of heavy materialization; on the other hand, the existing heavy materialization usually only targets scalar values or simple expressions with short computation chains and no side effects, and lacks a fine effectiveness verification mechanism when dealing with complex instructions, cross-basic block data streams and special hardware states, and the compiler is difficult to completely prove that the source instruction has a consistent vector environment and operand state at the heavy insertion point and the original definition point, and once the judgment is wrong, the program semantics will be destroyed; moreover, the traditional heavy materialization mechanism is a simple replacement overflow optimization loosely coupled with the general register allocation process, and does not have the dynamic decision-making ability for high register pressure scenarios, and cannot make a trade-off between "overflow memory I / O" and "recalculation" according to the cost, and in the RVV high lmul configuration, the overflow cost rises sharply, and the existing static heavy materialization mechanism cannot perceive this dynamic change, so it is difficult to play its due role in this particular scenario.

[0068] To solve the problem of how to avoid or bypass the huge performance overhead brought by traditional register overflow when the RISC-V vector processor faces high register pressure, the embodiment proposes a dynamic management method for RISC-V vector register pressure, which combines vector environment, runtime register pressure and hardware characteristics to build a special dynamic cost evaluation and decision-making mechanism, and under the premise of ensuring the correctness of the program semantics, uses heavy materialization to replace the high-overhead register overflow operation to solve the performance loss problem caused by high register pressure. Preferably, the method can be implemented in the register allocation and optimization pass of the static AOT compiler, or in the JIT compiler or runtime system, specifically, the method is integrated in the RISC-V backend register allocation stage, and the compiler makes overflow / heavy materialization decisions according to the register pressure and the cost model when generating the target code, or the method is part of the runtime system or JIT compiler, and dynamically evaluates and selects the corresponding strategy according to the actual runtime register usage state and hardware characteristics during program execution, and both deployment methods can implement the method proposed above.

[0069] AsFigure 1 The dynamic management method proposed in the embodiment specifically includes the following steps:

[0070] Step S1, in the process of program compilation or execution, the use state of the RISC-V vector register is monitored in real time, and when it is monitored that the vector register pressure is out of limit, the target register is selected and the management strategy is triggered.

[0071] Specifically, step S1 is a triggering step. In the process of program compilation or execution, the use state of the RISC-V vector register is monitored in real time. When it is detected that the vector register pressure is too high, that is, the register allocator needs to allocate a register for a new vector value, but all available physical registers are occupied, one or more vector registers (hereinafter referred to as target registers) need to be released for subsequent instructions, at this time, the management method is triggered, and one or more currently active registers are selected as target registers for release processing.

[0072] As an implementation manner, when selecting the target register, the preset heuristic rule can be selected. Specifically, by monitoring the register pressure, the use information of all active vector registers can be obtained, and the next use position of the vector value corresponding to each register in the subsequent code is counted. When the register needs to be released, the vector register whose next use point is farthest from the current program position is preferentially selected as the target register.

[0073] Further, when there are multiple candidate registers with the same or similar next use distance, the dynamic cost estimation strategy proposed in the embodiment can also be combined to estimate the re-materialization cost and register overflow cost of the vector value corresponding to each candidate register, and the register with the lowest re-materialization extension cost and the largest difference between the re-materialization cost and the overflow cost is preferentially selected as the target register, so as to reduce the overall performance overhead.

[0074] Step S2, identify the source instruction of the vector value in the target register, and perform re-materialization effectiveness verification, and divide the vector value into two categories of re-materializable and non-re-materializable according to the verification result.

[0075] Specifically, step S2 is an analysis and verification step, which first analyzes the origin of the vector value stored in the target register and the re-computation feasibility, including:

[0076] Step S2.1, trace the definition instruction of the vector value in the target register, that is, identify the source instruction of the vector value.

[0077] In this embodiment, the trace of the vector value definition instruction in the target register can be realized based on the intermediate representation (IR) inside the compiler and the data flow analysis technology. Specifically, the compiler usually maintains the mapping relationship between the register or virtual register and the intermediate value when constructing the intermediate representation, and maintains the definition-use (Def-Use) chain and / or data flow graph of each intermediate value. On this basis, the existing data structures can be used to reverse trace the definition instruction of the register value from the use point of the current target register, thereby completing the trace and identifying the source instruction of the vector value. The specific data flow analysis algorithm, SSA form (static single assignment form), Def-Use chain maintenance method, etc. in the implementation process of the trace operation are realized by using the existing compiler technology.

[0078] As another embodiment, the identification of the last definition position of each physical / logical vector register can be maintained during the register allocation stage, and when the register is selected as the target register, the corresponding source instruction can be directly located through the identification.

[0079] Further, after obtaining the source instruction, the heavy materialization strategy and the register overflow strategy are dynamically decided in combination with the heavy materialization effectiveness verification and the dynamic cost model, including:

[0080] Step S2.2, performing heavy materialization effectiveness verification on the identified source instruction. In this embodiment, the verification includes but is not limited to:

[0081] (1) operand activity check: checking whether all input operands (such as scalar registers, other vector registers) required by the source instruction remain valid and are not redefined at the future reinsertion point.

[0082] (2) context consistency check: checking whether the vector environment (such as sew, lmul in vtype register and vta, vma) and the mask state required by the execution of the source instruction are consistent with the reinsertion point.

[0083] (3) side effect and safety check: checking whether the source instruction involves non-deterministic operation, has side effect (Side Effects), or involves a memory area (non-readonly memory) that can be modified.

[0084] Secondly, according to the verification result and the source instruction calculation overhead, the vector value is divided into two categories: heavy materializable (low calculation overhead, verification passed) and non-heavy materializable (large calculation overhead or verification failed), including:

[0085] Step S2.3, dividing the vector value into two categories: heavy materializable and non-heavy materializable according to the verification result, for:

[0086] (1) Rematerializable: If the source instruction computation overhead is low (e.g., the source instruction computation overhead of the vector value is lower than the set value) and passes the above verification of rematerialization validity (or although the environment is inconsistent, it can be recovered through low-overhead instructions), then the vector value is classified as a rematerializable vector value.

[0087] (2) Non-reproducible vector values: These are vector values ​​that have huge computational overhead (the computational overhead of the original instruction of the vector value is higher than the set value) or have not passed the above verification of reproducibility validity, such as when the operand has been destroyed and cannot be recovered.

[0088] Step S3: Based on the partitioning results, dynamically estimate the materialization cost and register overflow cost.

[0089] Specifically, step S3 above is the cost assessment step, which first estimates the cost of register overflow. The cost by and current The impact of the value includes the instruction overhead and memory access latency of the vector store instruction and subsequent vector load instructions. Specifically, it includes the overhead of executing a vector store instruction (such as vse.v) to write the contents of the target register to memory, and the total overhead of executing a vector load instruction (such as vle.v) to read the value back into the register when needed, including instruction overhead and memory access latency. Therefore, the register overflow cost... The estimation formula can be expressed as:

[0090] ;

[0091] In the above formula, The overhead of vector storage instructions, This is to cover the overhead of subsequent vector loading instructions. This is the overhead of memory access latency.

[0092] Secondly, the materialization cost of heavy materials is estimated based on the above classification results. If the vector value is determined to be of a non-reproducible type, then it is... It is considered to be infinity or a very large preset value; if the determination vector value is a reproducible material type, then Includes the overhead of re-executing the source instructions, as well as the additional overhead required to maintain consistency, such as the overhead of inserting the vsetvli recovery environment or reloading scalar operands.

[0093] Step S4: Compare the two types of costs. If the cost of rematerialization is higher, then the decision is to adopt the register overflow strategy and execute it; if the cost of register overflow is higher, then the decision is to adopt the rematerialization strategy and execute it.

[0094] Specifically, the step S4 is a decision step, comparing the two estimated cost values and , if , the decision adopts the heavy materialization strategy and executes, including: not generating the instruction storing the target register (i.e. allowing its content to be overwritten), instructing the register allocator to overwrite the target register, and when the vector value in the target register is needed again in the subsequent code flow, generating the necessary environment recovery code, and then re-inserting the source instruction to calculate the vector value; and if , the decision adopts the traditional register overflow strategy and executes, including: generating the vse.v instruction and the like to store the content of the target register into the memory (such as the stack), and generating the vle.v instruction and the like to recover the vector value at the subsequent need point.

[0095] Embodiment Two

[0096] This embodiment proposes a dynamic management system for RISC-V vector register pressure, as shown in Figure 2 , the system includes:

[0097] A register pressure monitoring module, configured to monitor the usage state of the RISC-V vector register in real time during the program compilation or execution process, and select a target register and trigger a management strategy when the vector register pressure is out of limit;

[0098] A vector value analysis and verification module, configured to identify the source instruction of the vector value in the target register, and perform heavy materialization effectiveness verification, and divide the vector value into two categories of materializable and non-materializable according to the verification result;

[0099] A dynamic cost evaluation module, configured to dynamically estimate the heavy materialization cost and the register overflow cost according to the division result;

[0100] A decision and code generation module, configured to compare the two costs, if the heavy materialization cost is higher, the decision adopts the register overflow strategy and executes; and if the register overflow cost is higher, the decision adopts the heavy materialization strategy and executes.

[0101] As an implementation, the system described in this embodiment can be implemented as a Just-In-Time (JIT) compiler or an optimization pass of an Ahead-of-Time (AOT) compiler, for example, it can be a customized register allocation strategy module for RISC-V backend in the LLVM (Low Level Virtual Machine) compiler framework. Specifically, taking the RISC-V vector register pressure dynamic management system integrated in the JIT compiler as an example, the core modules for performing the register allocation phase are described in detail:

[0102] First, for the register pressure monitoring module 101, the module is usually part of the register allocator (for example, a graph coloring or linear scan based allocator) in the JIT compiler, and its function is to track the allocation state and active interval of the RISC-V physical vector register in real time. When the register allocator needs to allocate a logical vector register for a new vector value (for example, the result of a vadd.vv instruction), but finds that all available physical registers (considering the current configuration, for example there are only 8 logical registers) are already occupied, the module is triggered at this time, and the module selects one or more currently active registers to release.

[0103] Second, for the vector value analysis module 102, it receives the victim register, i.e., the target register identifier, such as V8, from the register pressure monitoring module 101, at which time the module accesses the intermediate representation (IR) of the JIT compiler, such as a data flow graph (DAG) in the form of static single assignment (SSA), and performs data flow backtracking and classification, i.e., backtracking the defining instruction of the victim register V8, comparing the defining instruction with a predefined cheap rematerialization set. Examples (non-limiting) of the instruction set are as follows:

[0104] vmv.v.x / vfmv.v.f: scalar broadcast;

[0105] vmv.v.i: immediate number broadcast;

[0106] vbroadcast instruction: RVV 1.0;

[0107] viota.v: generate sequence;

[0108] vle.v loads a mask of all ones from read-only memory (ROM);

[0109] A short chain of only 1-2 simple arithmetic instructions (e.g. vadd.vi, vmul.vx) whose operands are also cheap.

[0110] Finally, the module makes a decision: if the defining instruction belongs to the set, it marks the value as class A: re-materializable, and records its source instructions (e.g. vmv.v.x v8, x10); if the defining instruction does not belong to the set (e.g. it is a regular vle.v memory load or the result of a complex vfdiv.vv), it marks the value as class B: not re-materializable.

[0111] Then, for the dynamic cost evaluation module 103, it receives the victim register V8 and its classification (class A or class B), and if it is class A, it also receives the source instructions. The dynamic cost evaluation module has a hardware characteristic database 103a, i.e. it maintains or queries a database internally, which stores the key performance parameters of the target RISC-V processor, including:

[0112] L2 / L3 cache miss latency: for example cycles;

[0113] Memory bus bandwidth: for example bytes / cycle;

[0114] Execution latency of each vector instruction: for example cycles.

[0115] In addition, the module integrates a cost calculation function, which can calculate the overflow cost and the re-materialization cost . Among them, the overflow cost is a fixed high overhead, and its calculation process is:

[0116] First, get the current and , calculate DataSize =(vlen / 8)*lmul bytes;

[0117] Second, calculate , estimate example: . Further, in bit (32B), DataSize = 256 bytes, at this time cycles.

[0118] Heavy materialization cost The calculation process is as follows:

[0119] If the register is B class, i.e. not heavy materializable, then (infinite) ;

[0120] If the register is A class, i.e. heavy materializable, then For example, the source instruction is vmv.v.x v8, x10, cycles.

[0121] Finally, the dynamic cost evaluation module outputs two cost values and .

[0122] Finally, for the decision and code generation module 104, it receives and and makes a decision, if then the decision is heavy materialization strategy, otherwise the decision is register overflow strategy, and the module modifies the code generation phase of the JIT compiler.

[0123] When the decision is heavy materialization, the register allocator 101 is instructed to forget the current value of the V8 and directly allocate it to the new instruction, i.e. allow V8 to be overwritten, and no vse.v (store) instruction is generated, and all uses of V8 in the subsequent code are scanned, and before each use point, the source instruction of V8 is re-inserted, for example vmv.v.x v8, x10.

[0124] When the decision is register overflow, the standard process of the prior art is executed, i.e. space is allocated on the stack, a vse.v instruction is generated, for example vse256.v V8, 128(sp), V8 is stored into the stack, the register allocator 101 is instructed to release V8, and before the use point of V8 in the subsequent code, a vle.v instruction is inserted, for example vle256.v V8, 128(sp), to recover it from the stack.

[0125] As an implementation, the above implementation details and boundary condition processing specifically include:

[0126] ​1) Mask / Tail Strategy Compatibility: Ensure the same vtype / vta / vma and mask register state as the original definition point when inserting the source instruction; if not, prohibit the re-materialization of this value.

[0127] 2) Loop and Multiple Usage Points: For multiple usages in a loop body, allow one-time re-materialization at the loop entry and reuse within the body, or local re-materialization at each usage point; select the scheme by heuristics according to loop unrolling, scheduling gap, and register pressure.

[0128] 3) Instruction Scheduling and Port Contention: Modify the execution port conflict, front-end bandwidth, and instruction cache locality in the optional Adjust For Scheduling to avoid inserting too many instructions at hotspots.

[0129] 4) Exceptions and IEEE754: For source instructions that may generate floating-point exceptions or NaN propagation differences, disable re-materialization by default unless strict mode equivalence verification is set.

[0130] 5) Special Handling for Read-Only Loads: For read-only vector loads from constant pools or.rodata, treat them as Class A by converting constants to immediate broadcasts and light arithmetic chains.

[0131] 6) Operand Register Consistency and Protection: If scalar (e.g., x10) or vector operands relied upon by the source instruction may be overwritten before the insertion point, do: a) mark them as reserved and prohibit overwriting; or b) build a short chain re-materialization for the operand; or c) save / restore them. If the resulting expansion cost is no longer optimal, fall back to spilling.

[0132] 7) Control Flow Path Consistency and In-Branch Local Re-Materialization: When operands on different paths may take different values, use in-path local re-materialization or insert conditional merge instructions; the cost is weighted by path probability and incorporated into the model.

[0133] 8) Cross-Call and Call Conventions Handling: For usage points that cross function calls, follow the ABI constraints on caller-saved registers; if necessary, save / restore before and after the call or reconstruct scalars before performing vector re-materialization at the usage point.

[0134] 9) Expansion Cost Model: Use = source instruction chain latency + environment restoration (e.g., vsetvli) + scalar save / restore + in-branch repeated insertion + scheduling penalty term; only when select re-materialization.

[0135] ​10) Fast rejection condition: Once it is found that uncontrollable alias write, frequent vtype switch, port saturation causing critical path inflation or too much extra state to save, directly reject rematerialization, fall back to spill.

[0136] 11) Optional state tracking structure: Introduce Operand Snapshot / Validity bit and Remat Chain description to track operand equivalence and availability of inserted sequences during register allocation and scheduling phase.

[0137] wherein, the Operand Snapshot refers to an operation number snapshot, that is, during the register allocation or scheduling process, the state information of one or more operation numbers (including scalar registers, vector registers or memory operation numbers, etc.) is recorded, which is used for subsequent judgment whether the operation number is still in the expected state; the Validity bit refers to a valid bit, that is, a state flag bit associated with the operation number snapshot or a specific operation number, which is used to indicate whether the operation number is still valid, whether it has not been covered or destroyed. The embodiment can track the equivalence and availability of the operation number during the register allocation and scheduling phase by maintaining the Operand Snapshot and its corresponding Validity bit, thereby assisting in deciding whether to perform the rematerialization strategy.

[0138] In addition, Remat is an abbreviation of rematerialization, and the Remat Chain refers to a rematerialization chain, that is, a data structure used to describe "the source instruction sequence and its dependency relationship that needs to be re-executed in order to rematerialize a certain vector value" inside the compiler. The chain can include the definition instruction itself that generates the value, as well as a short instruction sequence that needs to be executed to ensure environmental consistency and operand availability.

[0139] Based on the above system, the embodiment shows that it can guarantee data consistency in dynamic decision-making through the following specific workflow when processing AI kernel functions (such as an inner loop of GEMM). Among them, GEMM (General Matrix-Matrix Multiplication, general matrix multiplication operation) is usually represented as multiplying two matrices and optionally weighting and accumulating a third matrix. GEMM is one of the basic computing kernel functions widely used in linear algebra libraries and high-performance computing, commonly used in artificial intelligence, machine learning and scientific computing scenarios.

[0140] Firstly, the scene setting includes:

[0141] Hardware settings: RISC-V processor, bit (32 bytes);

[0142] Code setting: JIT compiler is compiling a compute-intensive loop, register allocator configures ;

[0143] Hardware characteristic setting: overflow cost Estimation: 316 cycles; broadcast instruction vmv.v.x delay is 2 cycles;

[0144] State setting: register pressure is extremely high Only 4 logical registers are available, V0, V8, V16 are all occupied, and the new instruction vadd.vv V24, V0, V16 needs to allocate V24, but V24 is occupied.

[0145] At this time, the register allocator 101 selects V8 (assuming that the next use point of V8 is the farthest) as the victim, i.e., as the target register.

[0146] Secondly, the vector value analysis module 102 intervenes, traces back the IR to find the data source of V8, performs source instruction identification: finds that V8 is defined in the instruction vmv.v.x V8, x10; performs dependency identification: identifies that the instruction depends on the scalar register x10, and depends on the current vector environment when executed (assuming that the definition type is e32, m8).

[0147] Thirdly, the vector value analysis and verification module 102 performs re-materialization validity verification, including:

[0148] Step A, instruction overhead check: vmv.v.x belongs to the pre-defined cheap instruction set;

[0149] Step B, operand activity check: the system scans the data flow graph (DAG) to check whether the scalar register x10 is redefined between the current point and the future expected re-insertion point.

[0150] The final detection result is: it is confirmed that x10 is not modified.

[0151] Step C, environment consistency check: the system compares the expected of the re-insertion point with the required of the source instruction, and the detection result is that the assumption is consistent, or inconsistent but the recovery cost is extremely low, at this time V8 passes all the verification and is marked as A-class-re-materializable.

[0152] Then, cost evaluation is performed through the dynamic cost evaluation module, and : based on , 316 cycles are calculated; and , since step C determines that the environment is consistent and the recovery cost is 0, then .

[0153] Finally, the decision and code generation module 104 intervenes, comparing If so, the heavy materialization strategy is executed, i.e. the module 104 instructs the register allocator to directly override V8, not to generate the vse.v store instruction, and to execute the heavy insertion logic: before the use point vfmul.vv V0, V0, V8 at instruction 20, the system again checks the current state (inserting vsetvli if there is a change, which is assumed not to be the case in this embodiment), and the system re-inserts the source instruction vmv.v.x V8, x10, generating the use instruction vfmul.vv...

[0154] Embodiment three

[0155] The embodiment provides an electronic device, comprising: a memory, configured to store executable instructions; and a processor, configured to execute the executable instructions stored in the memory, so as to implement the method provided in the embodiment.

[0156] Embodiment four

[0157] The embodiment also provides a computer readable storage medium storing executable instructions, when the executable instructions are executed by a processor, the processor executes the method provided in the embodiment.

[0158] Embodiment five

[0159] The embodiment provides a computer program product, the computer program product comprises executable instructions, the executable instructions are a kind of computer instructions;The executable instructions are stored in computer readable storage medium.When the processor of electronic device reads the executable instructions from the computer readable storage medium, the processor executes the executable instructions, so that the electronic device executes the method provided in the embodiment.

[0160] The steps and method embodiments one corresponding to the above embodiments two to five are involved, and the specific embodiment can refer to the related description part of embodiment one.The term "computer readable storage medium" should be understood as including a single medium or multiple media of one or more instruction sets;It should also be understood as including any medium capable of storing, encoding or carrying instruction set for execution by processor and causing processor to execute any method in the present application.

[0161] Those skilled in the art should understand that the modules or steps of the present application described above can be realized by a general computer device, alternatively, they can be realized by program codes executable by a computing device, so that they can be stored in a storage device and executed by a computing device, or they can be respectively made into individual integrated circuit modules, or a plurality of modules or steps among them can be made into a single integrated circuit module to realize. The present application is not limited to any specific combination of hardware and software.

[0162] The above only describes the preferred embodiments of the present application, and the specific embodiments of the present application are described in conjunction with the drawings, but are not limited to the protection scope of the present application. Those skilled in the art should understand that various modifications or changes made by those skilled in the art on the basis of the technical solutions of the present application without creative labor are still within the protection scope of the present application.

Claims

1. A method for dynamic management of RISC-V vector register pressure, comprising: The method comprises the following steps: During the program compilation or execution, the use state of the RISC-V vector register is monitored in real time, when it is monitored that the vector register pressure is out of limit, a target register is selected and a management strategy is triggered; The source instruction of the vector value in the target register is identified, and the materialization effectiveness verification is performed, and according to the verification result, the vector value is divided into two categories of materializable and non-materializable; According to the division result, the materialization cost and the register overflow cost are dynamically estimated; The register overflow cost includes the instruction overhead of the vector storage instruction and the subsequent vector loading instruction and the memory access delay overhead; The register overflow cost The estimation formula is: ； In the above formulae, overhead for a vector store instruction, overhead for a subsequent vector load instruction, overhead for a memory access latency; The calculation of the materialization cost includes: If the vector value in the target register is non-materializable, the materialization cost is infinite; If the vector value in the target register is materializable, the materialization cost includes the overhead of re-executing the source instruction and the additional overhead required to meet the consistency; wherein the additional overhead includes the environment recovery overhead and the scalar operand reloading overhead; The two types of costs are compared, if the materialization cost is higher, the register overflow strategy is decided to be adopted and executed, if the register overflow cost is higher, the materialization strategy is decided to be adopted and executed.

2. The method for dynamic management of RISC-V vector register pressure according to claim 1, wherein, The materialization effectiveness verification includes: The operand activity check is to confirm that the input operand required by the source instruction remains valid and is not redefined at the future re-insertion point; The context consistency check is to confirm that the vector environment required by the execution of the source instruction is consistent with the re-insertion point; The side effect and safety check confirms that the source instruction does not involve non-deterministic operation, has no side effect and does not involve a modifiable memory region.

3. The method for dynamic management of RISC-V vector register pressure according to claim 1, wherein, According to the verification result, the vector value is divided into two categories of materializable and non-materializable, which includes: When the source instruction calculation overhead of the vector value is lower than the set value, and the materialization effectiveness verification is passed, or the environment is inconsistent and can be recovered by low-overhead instructions, the vector value is divided into materializable vector value; When the original instruction calculation overhead of the vector value is higher than the set value, or the materialization effectiveness verification is not passed, the vector value is divided into non-materializable vector value.

4. The method for dynamic management of RISC-V vector register pressure according to claim 1, wherein, Adopting the register overflow strategy and executing is to generate a storage instruction to store the vector value in the target register into the memory, and generate a loading instruction at the subsequent use point to recover the vector value; Adopting the materialization strategy and executing is to not generate the storage instruction of the target register, instructing the register allocator to cover the target register, and when the vector value in the target register is needed at the subsequent use point, generating the necessary environment recovery code and re-inserting the source instruction to calculate the vector value.

5. A system for dynamic management of RISC-V vector register pressure, comprising: The method comprises the following steps: The register pressure monitoring module is used for monitoring the use state of the RISC-V vector register in real time during the program compilation or execution, when it is monitored that the vector register pressure is out of limit, a target register is selected and a management strategy is triggered; The vector value analysis and verification module is used for identifying the source instruction of the vector value in the target register, and performing the materialization effectiveness verification, and according to the verification result, the vector value is divided into two categories of materializable and non-materializable; The dynamic cost evaluation module is used for dynamically estimating the materialization cost and the register overflow cost according to the division result; The register pressure monitoring module is used for monitoring the use state of the RISC-V vector register in real time during the program compilation or execution, when it is monitored that the vector register pressure is out of limit, a target register is selected and a management strategy is triggered; The register overflow cost includes instruction overhead and memory access delay overhead of the vector store instruction and a subsequent vector load instruction; The register overflow cost The estimation formula is: ； In the above formulae, overhead for a vector store instruction, overhead for a subsequent vector load instruction, overhead for a memory access latency; The calculation of the heavy materialization cost includes: If the vector value in the target register is not heavy materializable, the heavy materialization cost is infinite; If the vector value in the target register is heavy materializable, the heavy materialization cost includes the overhead of re-executing the source instruction and additional overhead required to meet consistency; wherein the additional overhead includes environment recovery overhead and scalar operand reloading overhead; A decision and code generation module is configured to compare the two types of costs, if the heavy materialization cost is higher, the decision is to adopt the register overflow strategy and execute; if the register overflow cost is higher, the decision is to adopt the heavy materialization strategy and execute.

6. An electronic device, comprising: It includes: A memory for storing executable instructions; A processor for executing the executable instructions stored in the memory, realizing the dynamic management method for RISC-V vector register pressure according to any one of claims 1-4.

7. A computer readable storage medium characterized in that, Executable instructions are stored for causing the processor to execute the executable instructions, realizing the dynamic management method for RISC-V vector register pressure according to any one of claims 1-4.

8. A computer program product, characterised in that, The computer program product includes executable instructions stored in a computer readable storage medium; When the processor of the electronic device reads the executable instructions from the computer readable storage medium and executes the executable instructions, the dynamic management method for RISC-V vector register pressure according to any one of claims 1-4 is realized.

Images