Heterogeneous code translation method and device, equipment and medium

Abstract

The invention provides a heterogeneous code translation method and device, equipment and a medium. The method comprises the following steps: acquiring a source program heterogeneous code running in a source heterogeneous hardware system; compiling the source program heterogeneous code to generate an intermediate representation of a source heterogeneous hardware system; mapping the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; and mapping the LLVM intermediate representation to obtain an RISC-V extension code, and the RISC-V extension code is used for running on the target hardware system. According to the method, the suitability between the code and the target hardware system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a heterogeneous code translation method, device, equipment and medium. Background Art

[0002] With the development of technology, codes developed by programming languages ​​need to run on a variety of operating systems and hardware systems, especially in scenarios that require high performance and close to hardware-level operations. Programming languages ​​are widely used in system software, embedded systems and other fields due to their powerful performance and flexibility.

[0003] However, the degree of compatibility between hardware systems and codes is different, and programmers are usually required to perform heterogeneous code translation for each hardware system separately to obtain code that is compatible with the hardware system. For example, in code compilation applications, traditional compilation methods usually require programmers to manually compile and optimize code for the target hardware system, resulting in low compatibility between the code and the target hardware system. Summary of the invention

[0004] In view of this, the embodiments of the present application are committed to providing a heterogeneous code translation method, apparatus, device and medium, which can shorten the time consumption of heterogeneous code translation and improve the efficiency of heterogeneous code translation.

[0005] In a first aspect, a heterogeneous code translation method is provided, the method comprising: obtaining source program heterogeneous code running on a source heterogeneous hardware system; compiling the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; mapping the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; mapping the LLVM intermediate representation to obtain a RISC-V extension code, the RISC-V extension code being used to run on a target hardware system.

[0006] In a second aspect, a heterogeneous code translation device is provided, which includes: a code acquisition module, configured to acquire source program heterogeneous code running on a source heterogeneous hardware system; a code compilation module, configured to compile the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; a first mapping module, configured to map the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; a second mapping module, configured to map the LLVM intermediate representation to obtain a RISC-V extended code, the RIS C -V extends the code to run on the target hardware system.

[0007] According to a third aspect, an electronic device is provided, comprising: one or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, execute the method described in the first aspect above.

[0008] According to a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method described in the first aspect is implemented.

[0009] According to a fifth aspect, a program product is provided, comprising computer program instructions, which, when executed by a processor, enable the processor to implement the method described in the first aspect.

[0010] This application compiles the source program heterogeneous code running on the source heterogeneous hardware system to generate the intermediate representation of the source heterogeneous hardware system, and maps the intermediate representation of the source heterogeneous hardware system to obtain the LLVM intermediate representation; next, the LLVM intermediate representation is mapped to obtain the RISC-V extension code suitable for running on the target hardware system. In this way, the source program heterogeneous code suitable for the source heterogeneous hardware system can be converted into the RISC-V extension code that can run on the target hardware system, which can improve the compatibility between the code and the target hardware system. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a schematic diagram of the architecture of the application scenario of the heterogeneous code translation method provided in the embodiment of the present application;

[0012] Figure 2 is a flow chart of a heterogeneous code translation method provided in an embodiment of the present application;

[0013] Figure 3 is a schematic diagram of a heterogeneous code translation method provided in an embodiment of the present application;

[0014] Figure 4 is a schematic diagram of a syntax tree provided in an embodiment of the present application;

[0015] Figure 5 is a schematic diagram of a heterogeneous code translation device provided in an embodiment of the present application;

[0016] Figure 6 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0018] The heterogeneous code translation method provided in this embodiment may include: obtaining source program heterogeneous code running on a source heterogeneous hardware system; compiling the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; mapping the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; mapping the LLVM intermediate representation to obtain a RISC-V extension code, which is used to run on a target hardware system, and can improve the compatibility between the code and the target hardware system.

[0019] For ease of understanding, this article first introduces the application scenarios to which the heterogeneous code translation method provided by this application is applicable. Figure 1 , the electronic device 110 is connected to the client 120 for communication:

[0020] The client 120 is used to send source program heterogeneous codes of the source heterogeneous hardware system to the electronic device 110;

[0021] Electronic device 110: used to obtain source program heterogeneous code running on a source heterogeneous hardware system; compile the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; map the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; map the LLVM intermediate representation to obtain a RISC-V extension code, which is used to run on a target hardware system.

[0022] The electronic device 110 may be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices.

[0023] Figure 2 A flowchart of a heterogeneous code translation method provided in an embodiment of the present application, in which the scheme is applied to Figure 1 The electronic equipment in the example is used to illustrate. Figure 2 As shown in , the method may include the following steps:

[0024] Step 201: Obtain source program heterogeneous codes running on a source heterogeneous hardware system.

[0025] Step 203: compile the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system.

[0026] Step 205: Map the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation;

[0027] Step 207: Map the LLVM intermediate representation to obtain RISC-V extension code, which is used to run on the target hardware system.

[0028] It can be seen that the present application generates an intermediate representation of the source heterogeneous hardware system by compiling the source program heterogeneous code running on the source heterogeneous hardware system, and maps the intermediate representation of the source heterogeneous hardware system to obtain the LLVM intermediate representation; next, the LLVM intermediate representation is mapped to obtain the RISC-V extension code suitable for running on the target hardware system. In this way, the source program heterogeneous code suitable for the source heterogeneous hardware system can be converted into the RISC-V extension code that can run on the target hardware system, which can improve the compatibility between the code and the target hardware system.

[0029] The following describes in detail each step in the above process and the effects that can be further produced in conjunction with the embodiments.

[0030] First, the above step 201, namely "obtaining source program heterogeneous codes running on source heterogeneous hardware systems", is described in detail in conjunction with the embodiments.

[0031] The embodiment of the present application can obtain source program heterogeneous codes from the source heterogeneous hardware system through the corresponding interface.

[0032] Here, a source heterogeneous hardware system may refer to a system composed of different types of hardware and software, and these components may have different architectures, operating systems, programming languages ​​or communication protocols, etc. Optionally, these components may be different types of processors (such as CPU (Central Processing Unit, central processing unit), GPU (Graphics Processing Unit, graphics processing unit)), storage devices (such as HDD (Hard Disk Drive, hard disk drive), SSD (Solid State Drives, solid state drive)), NIC (network interface card) and other hardware, or different operating systems (such as Windows, Linux), programming languages ​​(such as C, C++, Java), databases (such as MySQL, Oracle) and other software.

[0033] In the embodiments of the present application, the source program heterogeneous codes running on the source heterogeneous hardware system include but are not limited to: CUDA (Compute Unified Device Architecture) code, HIP (Heterogeneous-compute Interface for Portability) code or OPENCL (Open Computing Language) code.

[0034] That is to say, the embodiments of the present application convert source program heterogeneous codes applicable to a variety of different source heterogeneous hardware systems into scenarios of target hardware systems running RISC-V extension codes.

[0035] The above step 203, namely "compiling the heterogeneous code of the source program to generate an intermediate representation of the source heterogeneous hardware system", is described in detail below in conjunction with the embodiments.

[0036] The embodiment of the present application compiles the source program heterogeneous code of the source heterogeneous hardware system into an intermediate representation of the source heterogeneous hardware system through a compiler of a third-party development tool chain.

[0037] The intermediate representation of the source heterogeneous hardware system in the embodiments of the present application includes but is not limited to: NVIDIA's PTX (Parallel Thread Execution), AMD's HSAIL (Heterogeneous System Architecture Intermediate Language) or SPIR-V (Standard Portable Intermediate Representation-Vulkan).

[0038] In one example, the CUDA code is compiled into PTX virtual instructions by an open source compiler (such as Clang); or, the HIP code is compiled into HSAIL virtual instructions; or, the OPENCL code is compiled into SPIR-V virtual instructions by an OpenCL compiler.

[0039] Among them, PTX is the underlying parallel computing instruction architecture designed by NVIDIA for its CUDA programming environment.

[0040] HSAIL is an intermediate language designed by AMD for its HSA (Heterogeneous System Architecture) architecture. It is a virtual instruction designed by AMD and can be used to describe the code running on different computing devices (such as CPU, GPU, etc.). The compiler (such as the OpenCL compiler that supports HSA) compiles the source program heterogeneous code into HSAIL. When the program is executed by the HSA Runtime, the JIT (Just-in-Time Compilation) or AOT (Ahead-of-Time Compilation) mechanism is used to convert HSAIL into RISC-V extension code running on the target hardware system.

[0041] SPIR-V is a standard intermediate language that supports conversion of computing or graphics languages ​​such as OpenCL (Open Computing Language) and OpenGL (Open Graphics Library). The purpose is to provide a portable, high-performance intermediate representation that is easy to run on the target hardware system.

[0042] It should be noted that HSAIL, SPIR-V or PTX are GPU virtual instructions, which are used to write and execute code running on the GPU. The purpose of this type of virtual instructions is to provide a hardware-independent programming interface, allowing programmers to write code at a higher level without directly targeting specific hardware.

[0043] The above step 205, namely "mapping the intermediate representation of the source heterogeneous hardware system to obtain the LLVM intermediate representation", is described in detail below in conjunction with the embodiments.

[0044] The process of mapping the intermediate representation of the source heterogeneous hardware system to LLVM IR (Intermediate Representation) in the embodiment of the present application involves converting the operations, instructions and architectural features unique to the intermediate representation of the source heterogeneous hardware system into a general representation that can be represented by LLVM IR.

[0045] Among them, LLVM IR is used to provide a representation that is independent of the source program heterogeneous code and the target hardware system.

[0046] During the mapping process, the following mappings need to be performed for the operations, instructions, and architectural features specific to the intermediate representation of the source heterogeneous hardware system, which may include:

[0047] (1) Mapping GPU virtual instructions to operations or instruction sequences in LLVM IR. This requires decomposing GPU-specific operations into more basic operations that can be represented by LLVM IR. For example, some parallel computing instructions in the GPU may need to be converted into loops and vector operations in LLVM IR.

[0048] (2) Map registers to variables or memory locations in LLVM IR.

[0049] (3) During the mapping process, the memory access pattern is optimized to match the GPU’s access pattern.

[0050] (4) Convert control flow structures (such as branches and loops) into equivalent structures supported by LLVM.

[0051] In one example, the intermediate representation of the source heterogeneous hardware system is mapped to obtain the LLVM IR, which specifically includes:

[0052] (1) Parse the intermediate representation of the source heterogeneous hardware system to obtain the corresponding syntax tree and symbol table. For example, use the scanning parser to set the corresponding pattern matching rules and syntax rules, decompose the intermediate representation of the source heterogeneous hardware system into a series of tokens, and parse the token stream according to the corresponding syntax rules to construct the corresponding syntax tree and symbol table. The symbol table is used to store the symbol information included in the intermediate representation of the source heterogeneous hardware system, such as variable names, function names, etc. At the same time, the symbol table also tracks the symbol declarations of different scopes to ensure the visibility of the symbols and the normal management of their life cycle.

[0053] (2) Traverse the syntax tree and the symbol table, map the symbol information according to the first preset mapping rule, and generate LLVM IR. For example: through the mapper, traverse the syntax tree and the symbol table, and map the variables, registers, basic instructions, special instructions, etc. to the corresponding LLVM IR according to the first preset mapping rule. The first preset mapping rule includes the mapping relationship between the symbol information and the LLVM IR.

[0054] Among them, the symbol table is a table that records all the symbols that appear. Each symbol will store the following symbol information: such as name; storage address (memory address); type (such as function, register, global variable, local variable, shared memory variable, constant, input parameter, etc.); size (8, 16, 32, 64 bits, etc.); scope; a unique value id.

[0055] The following example uses mapping GPU virtual instructions to obtain LLVM IR.

[0056] For example, enter a GPU virtual instruction: add.u32 d,a,1;

[0057] exist Figure 3 In the compiler, the source program heterogeneous code is compiled to obtain GPU virtual instructions; the front-end scans and analyzes the GPU and divides a GPU virtual instruction into meaningful tags according to the established rules. Figure 4 In the figure, "add" represents the OPCODE tag of the GPU virtual instruction; ".u32" is the data type SCALAR_TYPE of the GPU virtual instruction; "a" and "d" are the specific names of two variables IDENTIFIER (identifier); "," is a COMMA character, and ";" is a SEMI_COLON character; "1" belongs to the immediate value INT_OPERAND.

[0058] The rules formulated are:

[0059] instruction:OPCODE SCALAR_TYPE operand_list SEMI_COLON;

[0060] operand_list(operand list):operand|operand_list COMMA operand;

[0061] operand:IDENTIFIER|INT_OPERAND;

[0062] Next, the above tokens (i.e., the tokens corresponding to "add"; ".u32"; "d"; ","; "a"; ";"; "1" respectively) are parsed according to the above rules to construct a syntax tree (such as Figure 4 as shown) and symbol table.

[0063] Next, the front end creates a class variable insn (instruction) based on the syntax tree (corresponding to Figure 4 Its OPCODE is add, its data type is u32, and it has three operands: d, a, and 1.

[0064] Before the front-end maps the GPU virtual instruction to LLVM IR through the mapper, the variables d and a have their declaration and definition in the input original text location where the GPU virtual instruction variable declaration instruction is located, otherwise the mapper reports an error. At its declaration, such as: .reg u32 d; the scanning parser knows that this is a register declaration based on the special tag .reg, and creates its information in the symbol table: the register name is "d", it is a register, the size is 32 bits, etc.

[0065] When the front-end maps the GPU virtual instruction to LLVM IR through the mapper, the information in the corresponding class variable is extracted. According to its OPCODE, the mapper uses the operation used to create the addition instruction in LLVM IR to create an add operation in LLVM IR. At this point, the front-end completes the mapping of GPU virtual instructions to LLVM IR.

[0066] Each GPU virtual instruction corresponds to an instantiated class variable, which contains the information of the GPU virtual instruction, including:

[0067] Operation code (OPCODE): used to indicate the operation corresponding to this GPU virtual instruction;

[0068] Operand: refers to the data used by this GPU virtual instruction;

[0069] Data type: indicates the data type involved in the GPU virtual instruction, such as int32, int64, float, etc. The input and output data types of some GPU virtual instructions are inconsistent and will be recorded;

[0070] Scope of action;

[0071] Special modifiers: GPU virtual instructions contain special modifiers. For example, hi in "mul.hi" is a special modifier, indicating the calculation method of this multiple multiplication instruction;

[0072] Matrix shape: Some matrix calculation instructions in GPU virtual instructions contain information indicating the matrix shape. For example, "mma.m8n8k16" means that the mma instruction is executed on a matrix with a shape of 8*8*16 data arrangement.

[0073] A unique value id.

[0074] The reason why the intermediate representation of the source heterogeneous hardware system is mapped to LLVM IR in the embodiment of the present application includes at least one of the following:

[0075] LLVM provides various interfaces for creating intermediate representations, which facilitates the mapping of the intermediate representations of source heterogeneous hardware systems to LLVMIR.

[0076] LLVM provides a series of intermediate representation optimization algorithms, such as constant folding algorithm, dead code elimination algorithm, loop optimization algorithm, etc. These optimization algorithms can be reused in subsequent steps;

[0077] LLVM supports the RISC-V backend, providing programmers with a powerful compilation and optimization platform. Incremental development and verification based on this can further expand the functionality and performance of LLVM to meet the growing needs of RISC-V applications;

[0078] LLVM has a rich tool ecosystem, LLVM IR-related tools and libraries for analyzing, optimizing, and converting LLVM IR.

[0079] After obtaining the LLVM IR, the method of the embodiment of the present application further includes: processing the LLVM IR using a preset optimization algorithm to obtain an optimized LLVM IR;

[0080] Among them, the preset optimization algorithm includes at least one of the following: a constant folding algorithm, a dead code elimination algorithm, and a loop optimization algorithm.

[0081] Among them, LLVM provides a series of algorithms for optimizing intermediate representations, such as constant folding algorithms, dead code elimination algorithms, loop optimization algorithms, etc. These optimizations can be reused in subsequent steps.

[0082] exist Figure 3 The middle end is an optimizer that uses various optimization algorithms to optimize the execution efficiency and resource utilization of LLVM IR. These optimization algorithms can reuse the middle end optimization algorithms provided by LLVM, or customize the optimization algorithms according to the conversion requirements to reduce space and time consumption.

[0083] Among them, the Constant Folding algorithm is an optimization algorithm in the compiler. It calculates and simplifies the constants in the expression during the compilation phase and replaces them with the result constants, thereby reducing the computational overhead at runtime and improving the execution efficiency and performance of the program.

[0084] The DCE (Dead Code Elimination) algorithm is an optimization algorithm in the compiler that aims to delete code that will not be executed in the program.

[0085] Optionally, the loop optimization algorithm may include:

[0086] Loop unrolling: Duplicate the code in the loop body multiple times to reduce the overhead of loop control statements. This can increase the iteration speed of the loop, but may increase the size of the code.

[0087] Loop invariant extraction: Move the calculation of the invariant in the loop to the outside of the loop to reduce the amount of calculation in the loop body. This can improve the execution efficiency of the loop and reduce unnecessary calculation overhead.

[0088] Loop intensity reduction: Through mathematical transformation or algorithm optimization, complex calculations in the loop are simplified into simpler calculations. This can reduce the computational intensity of the loop and improve program performance.

[0089] Loop merging and splitting: Merge multiple similar loops into one loop, or split a complex loop into multiple simple loops. This can optimize the execution order of the loops and reduce unnecessary computational overhead.

[0090] Loop parallelization: Using multithreading or parallel processing technology, the computational tasks within the loop body are distributed to multiple processor cores for simultaneous execution. This can significantly increase the execution speed of the loop, but requires additional synchronization and communication overhead.

[0091] After obtaining the LLVM IR, the embodiment of the present application optimizes the LLVM IR to improve execution efficiency. At the same time, the correctness of the LLVM IR can also be verified to ensure that it correctly reflects the intermediate representation of the source heterogeneous hardware system.

[0092] The above step 207, i.e., "mapping LLVM IR to obtain RISC-V extension code for running on the target hardware system", is described in detail below in conjunction with the embodiments.

[0093] In the embodiment of the present application, the back end is used to map LLVM IR to RISC-V extension code, and RISC-V is used to run on the target hardware system, thereby realizing the porting of the source program heterogeneous code running on the source heterogeneous hardware system to the target hardware system running the RISC-V extension code.

[0094] The application fields of RISC-V in the embodiments of the present application, such as embedded systems, edge computing, and data centers, correspondingly, the RISC-V extension code can be run on the hardware systems corresponding to the above-mentioned application fields, such as embedded hardware systems, Internet of Things devices (such as devices used for edge computing and data centers), or network processors (such as GPGPU simulators, HPC (High Performance Computing)) and other hardware.

[0095] It should be noted that the above only lists a few target hardware systems that run RISC-V extension code. Other hardware systems can be set up according to other application areas of the RISC-V structure, which will not be repeated here.

[0096] The embodiment of the present application converts the source program heterogeneous code running on the source heterogeneous hardware system into RISC-V extended code running on different target hardware systems, thereby improving the compatibility between the code and different target hardware systems.

[0097] It should also be noted that in the back end (such as Figure 3 In the process of mapping LLVM IR to RISC-V extension code by the backend in the backend, in addition to the mapping of basic instructions, more hardware mapping is involved, for example, mapping the memory access mode of the source heterogeneous hardware system to the memory hierarchy of the target hardware system running the RISC-V extension code, or converting the synchronization mechanism of the source heterogeneous hardware system to the synchronization instructions supported by the target hardware system running the RISC-V extension code.

[0098] Taking the source program heterogeneous code as HIP code and the target hardware system as GPGPU simulator as an example, although the HSA architecture and GPGPU simulator are both architectures for parallel computing, their parallel execution models are different. In order to map the synchronization mechanism of the HSA architecture to the GPGPU simulator running RISC-V extension code, it is necessary to ensure that the smallest parallel unit for synchronization work, that is, the thread, performs the same work at runtime. Based on this, when the HIP code runs on the GPGPU simulator, the same code needs to call and allocate thread block groups and thread blocks of the same granularity to complete the work when running on the GPGPU simulator. Among them, the same granularity means: (1) the hierarchy and calling capabilities of the thread are consistent with the HSA architecture; (2) the shared memory and global memory on the same level of architecture are consistent in location and sharing mechanism. Based on the alignment of the above two points, the synchronization mechanism of the HSA architecture can be mapped to the GPGPU simulator running RISC-V extension code.

[0099] Among them, Vortex is an open source GPGPU architecture. GPGPU has multiple parallel models and memory models. For example, the HSA architecture uses the work-item and workgroup parallel models, while the GPGPU simulator uses the warp and thread parallel models. Therefore, the work-item and workgroup parallel models of the HSA architecture need to be mapped to the warp and thread parallel models of the GPGPU simulator to ensure the consistency of execution semantics.

[0100] In one example, mapping LLVM IR to obtain RISC-V extended code may include: mapping instructions included in LLVM IR to RISC-V extended instructions according to a second preset mapping rule, the second preset mapping rule including: a mapping relationship between instruction mapping included in LLVM and RISC-V extended instructions; and constituting RISC-V extended code based on RISC-V extended instructions obtained by mapping.

[0101] The mapping relationship includes at least one of the following:

[0102] A mapping relationship between memory access instructions for a source heterogeneous hardware system and memory access instructions for a target hardware system;

[0103] A mapping relationship between a call instruction for a parallel computing resource in a synchronization mechanism of a source heterogeneous hardware system and a call instruction for a minimum parallel unit in a synchronization mechanism of a target hardware system.

[0104] The following examples take the HSA architecture with HSAIL as the intermediate representation of the source heterogeneous hardware system and the Vortex architecture with GPGPU as examples:

[0105] In the HSA architecture, wavefront represents the number of work-items that are scheduled together and executed in lock-step. Each work-item represents an execution thread. These work-items are organized into workgroups, which are further organized into queues. The same workgroup can communicate and synchronize efficiently through high-bandwidth local memory. All computing units can access GlobalMemory.

[0106] Each level in the Vortex hardware architecture provides different storage and computing resources. The highest level is GlobalMemory, which is accessible to all processors. The next level includes several clusters, each cluster contains multiple sockets, and each socket contains several cores. Each core has multiple warps, and each warp consists of multiple threads. Each core is equipped with L1 (first-level cache) cache, while each socket shares L2 (second-level cache) cache, and multiple clusters share L3 (third-level cache) cache.

[0107] The mapping relationship between the memory access instruction for the source heterogeneous hardware system and the memory access instruction for the target hardware system may refer to:

[0108] The memory model of the HSA architecture includes global memory, shared memory, and constant memory. However, the memory access methods of the GPGPU simulator may be different. The memory model of the HSA architecture needs to be mapped one by one with the memory model of the GPGPU simulator in order to run the HIP code completely and accurately on the GPGPU simulator. For example, the mapping between the global memory of the HSA architecture and the global memory of Vortex; the mapping between the work-item of the HSA architecture and the threads of the Vortex architecture; the mapping between the workgroup of the HSA architecture and the warp of the Vortex architecture.

[0109] Among them, the minimum parallel unit is different in different parallel computing architectures. For example, the minimum parallel unit corresponding to HSA refers to work-item.

[0110] It should also be noted that some special GPU virtual instructions cannot be accurately mapped to RISC-V instructions. RISC-V instruction extensions can be proposed for these special instructions. Based on the extended instructions, special GPU virtual instructions can be accurately mapped to RISC-V extended instructions. These extended instructions include but are not limited to at least one of the following:

[0111] 1) Warp-level data interaction instructions: shuffle, vote, and match;

[0112] 2) Warp-level mma (Matrix Multiply Accumulate) instructions;

[0113] 3) Special floating-point calculation instructions, such as tanh (Hyperbolic Tangent Function), ex2;

[0114] 4) Floating point atomic instructions;

[0115] 5) floating point conversion instructions involving bfloat16, tf32, f8(e4m3 and e5m2), f8(e4m3 and e5m2);

[0116] 6) Asynchronous data copy instructions;

[0117] 7) Some independent special instructions, such as lop3, prmt.

[0118] The embodiments of the present application have at least one of the following technical effects:

[0119] 1) Cross-hardware system support and code reuse can be achieved: This application converts the source heterogeneous hardware system code into RISC-V extension code, so programmers do not need to write programs specifically for RISC-V from scratch, and can reuse existing code on different hardware systems. This greatly reduces development time and cost, solves the problems of parallel model mapping, memory model adaptation, special instruction processing, and reduces the complexity of cross-hardware systems.

[0120] 2) It helps improve the performance of code adaptation to hardware: The RISC-V architecture has been widely adopted in the fields of embedded systems and edge computing, which often have stringent requirements on energy efficiency. By migrating the source program heterogeneous code of the source heterogeneous hardware system to the target hardware system running RISC-V, it is possible to reduce power consumption while ensuring computing performance, and improve the adaptability between the code and the target hardware system.

[0121] 3) It can ensure that the code of its source heterogeneous hardware system remains compatible and runs efficiently in the target hardware system, thereby extending the life cycle of the program and simplifying subsequent maintenance and upgrades.

[0122] 4) Using LLVM IR as the intermediate representation, the mapping from the intermediate representation of the source heterogeneous hardware system to the RISC-V extension code is completed. This method can be adapted to the source program heterogeneous code of a variety of source heterogeneous hardware systems and quickly complete the mapping from the source program heterogeneous code of the source heterogeneous hardware system to the target hardware system running the RISC-V extension code.

[0123] Combination of the above Figure 2 , describes the method embodiment of the present application in detail, and the following is combined with Figure 5 , describes the device embodiment of the present application in detail. It should be understood that the description of the method embodiment corresponds to the description of the device embodiment, so the parts not described in detail can refer to the previous method embodiment.

[0124] Figure 5 FIG. 1 is a schematic diagram of the structure of a heterogeneous code translation device provided by an embodiment of the present application. Figure 5 As shown, the heterogeneous code translation device provided in the embodiment of the present application includes a code acquisition module 501, a code compilation module 502, a first mapping module 503 and a second mapping module 504. Among them, the code acquisition module 501 is configured to acquire the source program heterogeneous code running on the source heterogeneous hardware system; the code compilation module 502 is configured to compile the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; the first mapping module 503 is configured to map the intermediate representation of the source heterogeneous hardware system to obtain the LLVM intermediate representation; the second mapping module 504 is configured to map the LLVM intermediate representation to obtain the RISC-V extension code, and the RISC-V extension code is used to run on the target hardware system.

[0125] In some embodiments, the source program heterogeneous code includes: CUDA code, HIP code or OPENCL code.

[0126] In some embodiments, the first mapping module 503 is further configured to:

[0127] Parsing the intermediate representation of the source heterogeneous hardware system to obtain a corresponding syntax tree and a symbol table, wherein the symbol table includes symbol information included in the intermediate representation of the source heterogeneous hardware system;

[0128] Traverse the syntax tree and the symbol table, map the symbol information according to a first preset mapping rule, and generate an LLVM intermediate representation, wherein the first preset mapping rule includes a mapping relationship between the symbol information and the LLVM intermediate representation.

[0129] In some embodiments, the intermediate representation of the source heterogeneous hardware system includes: HSAIL, SPIR-V, or PTX.

[0130] In some embodiments, the first mapping module 503 is further configured to:

[0131] According to a second preset mapping rule, the instructions included in the LLVM intermediate representation are mapped to RISC-V extended instructions, and the second preset mapping rule includes: a mapping relationship between the instruction mapping included in LLVM and the RISC-V extended instructions;

[0132] The RISC-V extended instructions obtained based on the mapping constitute the RISC-V extended code.

[0133] In some embodiments, the mapping relationship includes at least one of the following:

[0134] A mapping relationship between memory access instructions for a source heterogeneous hardware system and memory access instructions for a target hardware system;

[0135] A mapping relationship between a call instruction for a parallel computing resource in a synchronization mechanism of a source heterogeneous hardware system and a call instruction for a minimum parallel unit in a synchronization mechanism of a target hardware system.

[0136] In some embodiments, the apparatus further comprises:

[0137] An optimization module (not shown in the figure), configured to process the LLVM intermediate representation using a preset optimization algorithm to obtain an optimized LLVM intermediate representation;

[0138] Among them, the preset optimization algorithm includes at least one of the following: a constant folding algorithm, a dead code elimination algorithm, and a loop optimization algorithm.

[0139] In some embodiments, the target hardware system includes an embedded hardware system, an Internet of Things device, or a network processor.

[0140] Below, reference Figure 6 To describe an electronic device according to an embodiment of the present application. Figure 6 Shown is a schematic structural diagram of an electronic device provided in one embodiment of the present application.

[0141] like Figure 6 As shown, the electronic device includes one or more processors 601 and a memory 602 .

[0142] The processor 601 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions.

[0143] The memory 602 may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory (cache), etc. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on a computer-readable storage medium, and the processor 601 may run the program instructions to implement the functions of the heterogeneous code translation method of each embodiment of the present application mentioned above. Various contents such as model parameters and input data may also be stored in the computer-readable storage medium.

[0144] In one example, the electronic device may further include: an input device 603 and an output device 604, and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0145] The input device 603 may include, for example, a keyboard, a mouse, etc.

[0146] The output device 604 can output various information to the outside, including inference results, etc. The output device 604 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0147] Of course, to simplify, Figure 6 Only some of the components in the electronic device related to the present application are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, the electronic device may further include any other appropriate components according to specific application conditions.

[0148] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions. When the computer program instructions are executed by a processor, the processor executes the steps in the heterogeneous code translation method according to various embodiments of the present application described above in this specification.

[0149] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and also conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user electronic device, partially on the user device, as an independent software package, partially on the user electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server.

[0150] In addition, an embodiment of the present application may also be a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the steps of the heterogeneous code translation method according to various embodiments of the present application described above in this specification.

[0151] Computer readable storage media can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0152] The basic principles of the present application are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present application are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present application. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, not for limitation, and the above details do not limit the present application to being implemented by adopting the above specific details.

[0153] The block diagrams of the devices, apparatuses, equipment, and systems involved in this application are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0154] It should also be noted that in the apparatus, device and method of the present application, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0155] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0156] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

[0157] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A heterogeneous code translation method, wherein: The method comprises: Obtain source program heterogeneous codes running on source heterogeneous hardware systems; Compiling the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; Mapping the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; The LLVM intermediate representation is mapped to obtain a RISC-V extension code, and the RISC-V extension code is used to run on a target hardware system.

2. The method according to claim 1, wherein: The source program heterogeneous code includes: CUDA code, HIP code or OPENCL code.

3. The method according to claim 1, wherein: Mapping the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation includes: Parsing the intermediate representation of the source heterogeneous hardware system to obtain a corresponding syntax tree and a symbol table, wherein the symbol table includes symbol information included in the intermediate representation of the source heterogeneous hardware system; The syntax tree and the symbol table are traversed, and the symbol information is mapped according to a first preset mapping rule to generate an LLVM intermediate representation, wherein the first preset mapping rule includes a mapping relationship between the symbol information and the LLVM intermediate representation.

4. The method according to any one of claims 1 to 3, wherein: The intermediate representation of the source heterogeneous hardware system includes: HSAIL, SPIR-V or PTX.

5. The method according to claim 1, wherein: Mapping the LLVM intermediate representation to obtain the RISC-V extension code includes: According to a second preset mapping rule, the instructions included in the LLVM intermediate representation are mapped to RISC-V extended instructions, wherein the second preset mapping rule includes: a mapping relationship between the instruction mapping included in the LLVM and the RISC-V extended instructions; The RISC-V extended code is composed based on the RISC-V extended instructions obtained by mapping.

6. The method according to claim 5, wherein: The mapping relationship includes at least one of the following: A mapping relationship between memory access instructions for a source heterogeneous hardware system and memory access instructions for a target hardware system; A mapping relationship between a call instruction for a parallel computing resource in a synchronization mechanism of the source heterogeneous hardware system and a call instruction for a minimum parallel unit in a synchronization mechanism of the target hardware system.

7. The method according to claim 1, wherein: The method further comprises: Processing the LLVM intermediate representation using a preset optimization algorithm to obtain an optimized LLVM intermediate representation; Among them, the preset optimization algorithm includes at least one of the following: a constant folding algorithm, a dead code elimination algorithm, and a loop optimization algorithm.

8. The method according to any one of claims 1 to 3, wherein: The target hardware system includes: an embedded hardware system, an Internet of Things device or a network processor.

9. A heterogeneous code translation device, wherein: The device comprises: A code acquisition module is configured to acquire source program heterogeneous codes running on a source heterogeneous hardware system; A code compiling module, configured to compile the source program heterogeneous code to generate an intermediate representation of the source heterogeneous hardware system; A first mapping module is configured to map the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; The second mapping module is configured to map the LLVM intermediate representation to obtain a RISC-V extension code, where the RISC-V extension code is used to run on a target hardware system.

10. An electronic device, characterized in that: including memory and processor; The memory is connected to the processor and is used to store programs; The processor is configured to implement the method according to any one of claims 1 to 8 by running the program in the memory.

11. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1 to 8 is implemented.

12. A computer program product, characterized in that The method comprises computer program instructions, which, when executed by a processor, cause the processor to implement the method according to any one of claims 1 to 8.

Images