Heterogeneous code translation method, apparatus, device, and medium

Abstract

This application provides a method, apparatus, device, and medium for heterogeneous code translation. The method includes: acquiring heterogeneous source code running on a source heterogeneous hardware system; compiling the heterogeneous source 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; and mapping the LLVM intermediate representation to obtain RISC-V extended code, which is used to run on a target hardware system. This application improves the compatibility between code and target hardware systems.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, apparatus, device, and medium for heterogeneous code translation. Background Technology

[0002] With the development of technology, code developed using programming languages ​​needs to run on various operating systems and hardware systems, especially in scenarios requiring high performance and near-hardware-level operation. 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 code varies, usually requiring programmers to perform heterogeneous code translation for each hardware system to obtain code that is compatible with that 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 this application aim to provide a heterogeneous code translation method, apparatus, device and medium that can shorten the time consumption and improve the efficiency of heterogeneous code translation.

[0005] Firstly, a heterogeneous code translation method is provided, which includes: 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; and mapping the LLVM intermediate representation to obtain RISC-V extension code, which is used to run on a target hardware system.

[0006] Secondly, a heterogeneous code translation device is provided, comprising: 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; and a second mapping module configured to map the LLVM intermediate representation to obtain RISC-V extended code. C The -V extension code is used 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, perform the method described in the first aspect above.

[0008] According to a fourth aspect, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect above.

[0009] According to a fifth aspect, a program product is provided, including computer program instructions that, when executed by a processor, cause the processor to implement the method described in the first aspect above.

[0010] This application compiles heterogeneous source code running on a source heterogeneous hardware system to generate an intermediate representation of the source heterogeneous hardware system, and maps this intermediate representation to obtain an LLVM intermediate representation. Next, the LLVM intermediate representation is mapped to obtain RISC-V extension code suitable for running on a target hardware system. This method converts heterogeneous source code suitable for a source heterogeneous hardware system into RISC-V extension code that can run on the target hardware system, improving the compatibility between the code and the target hardware system. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the architecture of the heterogeneous code translation method provided in the embodiments of this application in a specific scenario;

[0012] Figure 2 This is a flowchart of the heterogeneous code translation method provided in the embodiments of this application;

[0013] Figure 3 This is a schematic diagram of the heterogeneous code translation method provided in the embodiments of this application;

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

[0015] Figure 5 This is a schematic diagram of the heterogeneous code translation device provided in the embodiments of this application;

[0016] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort 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 RISC-V extension code, which is used to run on the target hardware system, thereby improving the compatibility between the code and the target hardware system.

[0019] To facilitate understanding, this paper first introduces the application scenarios applicable to the heterogeneous code translation method provided in this application. See [link to relevant documentation]. Figure 1 Electronic device 110 communicates with client 120:

[0020] Client 120: Used to send heterogeneous source code of the heterogeneous hardware system to electronic device 110;

[0021] Electronic device 110: used to acquire source program heterogeneous code running on the 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 RISC-V extension code, which is used to run on the target hardware system.

[0022] Among them, electronic device 110 may be, but is not limited to, various personal computers, laptops, smartphones, tablets and portable wearable devices.

[0023] Figure 2 A flowchart illustrating the heterogeneous code translation method provided in this application embodiment, showing how this solution is applied... Figure 1 Let's take electronic devices as an example to illustrate. Figure 2 As shown, the method may include the following steps:

[0024] Step 201: Obtain the heterogeneous source code running on the source heterogeneous hardware system.

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

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

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

[0028] As can be seen, this application compiles the heterogeneous source code running on the source heterogeneous hardware system to generate an intermediate representation of the source heterogeneous hardware system, and maps the intermediate representation of the source heterogeneous hardware system to obtain an LLVM intermediate representation; next, it maps the LLVM intermediate representation to obtain RISC-V extension code suitable for running on the target hardware system. This method can convert heterogeneous source code suitable for the source heterogeneous hardware system into RISC-V extension code that can run on the target hardware system, thus improving the compatibility between the code and the target hardware system.

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

[0030] First, the above step 201, namely "obtaining the heterogeneous source code running on the heterogeneous hardware system", will be described in detail with reference to the embodiments.

[0031] The embodiments of this application can obtain heterogeneous source code from a heterogeneous hardware system through a corresponding interface.

[0032] Here, a heterogeneous hardware system can refer to a system composed of different types of hardware and software. These components may have different architectures, operating systems, programming languages, or communication protocols. Optionally, these components can be different types of processors (such as CPU (Central Processing Unit), GPU (Graphics Processing Unit)), storage devices (such as HDD (Hard Disk Drive), SSD (Solid State Drive)), NIC (Network Interface Card), etc., or different operating systems (such as Windows, Linux), programming languages ​​(such as C, C++, Java), databases (such as MySQL, Oracle), etc.

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

[0034] In other words, the embodiments of this application convert source code heterogeneous code applicable to various different source heterogeneous hardware systems into target hardware systems running RISC-V extended code.

[0035] The following describes step 203, namely "compiling the heterogeneous source code to generate an intermediate representation of the heterogeneous hardware system", in detail with reference to the embodiments.

[0036] This application embodiment uses a compiler from a third-party development toolchain to compile the heterogeneous source code of the source heterogeneous hardware system into an intermediate representation of the source heterogeneous hardware system.

[0037] The intermediate representations of the source heterogeneous hardware systems in this application embodiment include, but are 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, CUDA code is compiled into PTX virtual instructions using an open-source compiler (such as Clang); or, HIP code is compiled into HSAIL virtual instructions; or, OPENCL code is compiled into SPIR-V virtual instructions using an OpenCL compiler.

[0039] 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's a virtual instruction set designed by AMD to describe code that runs on different computing devices (such as CPUs and GPUs). Compilers (such as OpenCL compilers that support HSA) compile heterogeneous source code into HSAIL. When the HSA Runtime executes the program, it uses JIT (Just-In-Time) or AOT (Ahead-Of-Time) mechanisms to convert HSAIL into RISC-V extended code that runs on the target hardware system.

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

[0042] It's important to note that HSAIL, SPIR-V, or PTX are GPU virtual instructions used for writing and executing code that runs on the GPU. The purpose of these virtual instructions is to provide a hardware-independent programming interface, allowing programmers to write code at a higher level without directly interacting with specific hardware.

[0043] The following describes step 205, namely "mapping the intermediate representation of the source heterogeneous hardware system to obtain the LLVM intermediate representation", in detail with reference to the embodiments.

[0044] The process of mapping the intermediate representation of a source heterogeneous hardware system to LLVM IR (Intermediate Representation) involves converting the operation, instruction, and architectural characteristics unique to the intermediate representation of the source heterogeneous hardware system into a general representation that LLVM IR can represent.

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

[0046] During the mapping process, the following mappings need to be performed to address the unique operation, instruction, and architectural characteristics of the intermediate representation of the source heterogeneous hardware system. Specifically, these may include:

[0047] (1) Map GPU virtual instructions to operations or instruction sequences in LLVM IR. This requires breaking down GPU-specific operations into more basic operations that can be handled by LLVM IR. For example, some parallel computing instructions in the GPU may need to be translated into loop and vector operations in LLVM IR.

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

[0049] (3) During the mapping process, optimize the memory access mode to match the GPU's access mode.

[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 LLVM IR, specifically including:

[0052] (1) The intermediate representation of the source heterogeneous hardware system is parsed to obtain the corresponding syntax tree and symbol table. For example, a scanning parser is used to set the corresponding pattern matching rules and syntax rules, and the intermediate representation of the source heterogeneous hardware system is decomposed into a series of tags. The tag stream is then parsed 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 and function names. At the same time, the symbol table is also used to track symbol declarations in different scopes to ensure the visibility of symbols and the normal management of their lifecycle.

[0053] (2) Traverse the syntax tree and symbol table, and map the symbol information according to the first preset mapping rule to generate LLVM IR. For example, through the mapper, traverse the syntax tree and symbol table, and map 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 symbol information and LLVM IR.

[0054] The symbol table is a table that records all the symbols that appear. Each symbol stores the following information: name; memory address; type (e.g., function, register, global variable, local variable, shared memory variable, constant, input parameter, etc.); size (8, 16, 32, 64 bits, etc.); scope; and a unique ID.

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

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

[0057] exist Figure 3 In the process, the compiler compiles the heterogeneous source code to obtain GPU virtual instructions; the front-end, in the scanning parser, divides each GPU virtual instruction into meaningful tags according to defined rules. Specifically: Figure 4 In this code, "add" represents the OPCODE flag 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; "," is a COMMA character, ";" is a SEMI_COLON character; and "1" belongs to the immediate value INT_OPERAND.

[0058] The rules established are as follows:

[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, according to the rules established above, each of the above tags (i.e., the tags corresponding to "add", ".u32", "d", ",", "a", ";", and "1") is parsed 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 The instruction in the code has an OPCODE of add, a data type of u32, and three operands: d, a, and 1.

[0064] Before the front-end maps GPU virtual instructions to LLVM IR via the mapper, the variables 'd' and 'a' must be declared and defined at the input raw text location where the GPU virtual instruction variable declaration instruction is located; otherwise, the mapper will report an error. At their declaration location, such as: `.reg u32 d`; the scanner and parser, based on the special marker `.reg`, know that this is a register declaration and creates its information in the symbol table: the register name is "d", it is a register, its size is 32 bits, etc.

[0065] When the frontend maps GPU virtual instructions to LLVM IR through the mapper, information from the corresponding class variables is extracted. Based on its OPCODE, the mapper uses the operation in LLVM IR used to create an LLVM IR-style add operation. At this point, the frontend completes the mapping from GPU virtual instructions to LLVM IR.

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

[0067] Opcode: Used to indicate the operation corresponding to this GPU virtual instruction;

[0068] Operands: These are the data used in this GPU virtual instruction.

[0069] Data type: Indicates the data type involved in this GPU virtual instruction, such as int32, int64, float, etc. Inconsistent input and output data types in some GPU virtual instructions are also recorded.

[0070] Scope of application;

[0071] Special modifiers: GPU virtual instructions contain special modifiers, such as "hi" in "mul.hi", which is a special modifier that indicates how this multiple multiplication instruction is calculated;

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

[0073] A unique ID.

[0074] The reason why this application's embodiments map the intermediate representation of the source heterogeneous hardware system to LLVM IR includes at least one of the following:

[0075] LLVM provides various interfaces for creating intermediate representations, facilitating the mapping of intermediate representations from heterogeneous hardware systems to LLVMIR;

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

[0077] LLVM supports RISC-V backends, providing programmers with a powerful compilation and optimization platform. Incremental development and verification on this foundation can further expand LLVM's functionality and performance to meet the ever-growing demands of RISC-V applications.

[0078] LLVM has a rich ecosystem of tools, including LLVM IR-related tools and libraries for analyzing, optimizing, and transforming LLVM IR.

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

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

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

[0082] exist Figure 3 In the middleware, there is an optimizer that uses various optimization algorithms to improve the execution efficiency and resource utilization of LLVM IR. These optimization algorithms can either reuse the middleware optimization algorithms provided by LLVM or be customized according to transformation requirements to reduce space and time consumption.

[0083] Among them, the Constant Folding algorithm is an optimization algorithm in the compiler. It reduces runtime computational overhead and improves program execution efficiency and performance by calculating and simplifying constants in expressions during the compilation stage and replacing them with result constants.

[0084] The DCE (Dead Code Elimination) algorithm is an optimization algorithm in compilers designed to remove code from a program that will not be executed.

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

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

[0087] Loop invariant hoisting: This involves moving the calculation of invariants within a loop to the outside of the loop body, thereby reducing the amount of computation within the loop. This can improve the execution efficiency of the loop and reduce unnecessary computational overhead.

[0088] Loop strength reduction: By simplifying complex calculations within loops through mathematical transformations or algorithm optimization, the computational intensity of the loop can be reduced, thereby improving program performance.

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

[0090] Loop parallelization: This involves using multithreading or parallel processing techniques to distribute the computational tasks within a loop to multiple processor cores for simultaneous execution. This can significantly improve the execution speed of the loop, but it requires additional synchronization and communication overhead.

[0091] In this embodiment, after obtaining the LLVM IR, the LLVM IR is optimized to improve execution efficiency. Simultaneously, the correctness of the LLVM IR can be verified to ensure that it accurately reflects the intermediate representation of the source heterogeneous hardware system.

[0092] The following describes step 207, namely "mapping the LLVM IR to obtain RISC-V extension code for running on the target hardware system," in detail with reference to an embodiment.

[0093] In this embodiment, the backend 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 source program heterogeneous code running on the source heterogeneous hardware system to the target hardware system running RISC-V extension code.

[0094] The application areas of RISC-V in this application embodiment include embedded systems, edge computing, and data centers. Correspondingly, the RISC-V extension code can run on the hardware systems corresponding to the above application areas, such as embedded hardware systems, Internet of Things devices (such as devices for edge computing and data centers), or network processors (such as GPGPU simulators, HPC (High Performance Computing)).

[0095] It should be noted that the above are just some examples of target hardware systems for running RISC-V extended code. Other hardware systems can be configured according to other application areas of the RISC-V architecture, which will not be elaborated here.

[0096] This application embodiment converts the heterogeneous source 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] Additionally, it should be noted that in the backend (such as...) Figure 3 In the process of mapping LLVM IR to RISC-V extension code in the backend, in addition to mapping the 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 into the synchronization instructions supported by the target hardware system running the RISC-V extension code.

[0098] Taking the heterogeneous source code as HIP code and the target hardware system as a GPGPU simulator as an example, although both the HSA architecture and the GPGPU simulator are architectures oriented towards 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 extended code, it is necessary to ensure that the smallest parallel unit for synchronization, i.e., 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. Among them, the same granularity means: (1) the thread hierarchy and calling capability are consistent with the HSA architecture; (2) the shared memory and global memory are consistent in location and sharing mechanism on the same level of architecture. Based on aligning the above two points, the synchronization mechanism of the HSA architecture can be mapped to the GPGPU simulator running RISC-V extended code.

[0099] Vortex is an open-source GPGPU architecture with various parallel and memory models. For example, the HSA architecture uses work-item and workgroup parallel models, while the GPGPU simulator uses 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 consistency in execution semantics.

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

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

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

[0103] The mapping relationship between the instructions for calling parallel computing resources in the synchronization mechanism of the source heterogeneous hardware system and the instructions for calling the smallest parallel unit in the synchronization mechanism of the target hardware system.

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

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

[0106] Each layer in the Vortex hardware architecture provides different storage and computing resources. The highest layer is Global Memory, accessible to all processors. The next layers consist of clusters, each cluster contains multiple sockets, and each socket contains multiple cores. Each core contains multiple warps, and each warp consists of multiple threads. Each core is equipped with an L1 (Level 1) cache, while sockets share an L2 (Level 2) cache, and multiple clusters share an L3 (Level 3) cache.

[0107] The mapping relationship between memory access instructions for the source heterogeneous hardware system and memory access instructions for the target hardware system can be defined as follows:

[0108] The HSA architecture's memory model includes global memory, shared memory, and constant memory. However, the memory access methods of GPGPU emulators may differ. A one-to-one mapping between the HSA architecture's memory model and the GPGPU emulator's memory model is necessary to ensure that HIP code runs completely and accurately on the GPGPU emulator. Examples include mapping between HSA architecture's global memory and Vortex's global memory; mapping between HSA architecture's work-items and Vortex architecture's threads; and mapping between HSA architecture's workgroups and Vortex architecture's warps.

[0109] The minimum parallel unit varies in different parallel computing architectures. For example, the minimum parallel unit for HSA is the 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 these 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 commands: 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), and f8 (e4m3 and e5m2);

[0116] 6) Asynchronous data copy command;

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

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

[0119] 1) Enables cross-hardware system support and code reuse: This application converts the code from the source heterogeneous hardware system into RISC-V extended code, eliminating the need for programmers to write RISC-V-specific programs from scratch and allowing them to reuse existing code on different hardware systems. This significantly reduces development time and cost, solves problems such as parallel model mapping, memory model adaptation, and handling of special instructions, and reduces cross-hardware system complexity.

[0120] 2) Improves code compatibility with hardware performance: The RISC-V architecture is widely used in embedded systems and edge computing, scenarios that often have stringent requirements for energy efficiency. By migrating the heterogeneous source code from the source heterogeneous hardware system to the target hardware system running RISC-V, power consumption can be reduced while maintaining computing performance, thus improving the compatibility 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 an intermediate representation completes the mapping from the intermediate representation of the source heterogeneous hardware system to the RISC-V extension code. This method is adaptable to heterogeneous source code from various source heterogeneous hardware systems and quickly completes the mapping from the source heterogeneous source code of the source heterogeneous hardware system to the target hardware system running the RISC-V extension code.

[0123] The above text combined Figure 2 The method embodiments of this application are described in detail below, in conjunction with... Figure 5 The present application provides a detailed description of the apparatus embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.

[0124] Figure 5 The diagram shown is a structural schematic of a heterogeneous code translation device provided in an embodiment of this application. Figure 5 As shown, the heterogeneous code translation device provided in this embodiment includes a code acquisition module 501, a code compilation module 502, a first mapping module 503, and a second mapping module 504. The code acquisition module 501 is configured to acquire heterogeneous source code running on a source heterogeneous hardware system; the code compilation module 502 is configured to compile the heterogeneous source 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 an LLVM intermediate representation; and the second mapping module 504 is configured to map the LLVM intermediate representation to obtain RISC-V extension code, which is used to run on the target hardware system.

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

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

[0127] The intermediate representation of the source heterogeneous hardware system is parsed to obtain the corresponding syntax tree and symbol table. The symbol table includes the symbol information included in the intermediate representation of the source heterogeneous hardware system.

[0128] Traverse the syntax tree and symbol table, map the symbol information according to the first preset mapping rule, and generate the LLVM intermediate representation. The first preset mapping rule includes the mapping relationship between symbol information and 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 the second preset mapping rule, the instructions included in the LLVM intermediate representation are mapped to RISC-V extended instructions. The second preset mapping rule includes the mapping relationship between the instructions included in LLVM and the RISC-V extended instructions.

[0132] The RISC-V extension instructions obtained from the mapping are used to construct the RISC-V extension code.

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

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

[0135] The mapping relationship between the instructions for calling parallel computing resources in the synchronization mechanism of the source heterogeneous hardware system and the instructions for calling the smallest parallel unit in the synchronization mechanism of the target hardware system.

[0136] In some embodiments, the device further includes:

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

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

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

[0140] Below, for reference Figure 6 This describes an electronic device according to embodiments of the present application. Figure 6 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application.

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

[0142] The processor 601 may be a central processing unit (CPU) or other form of processing unit with 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, which 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. 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 the computer-readable storage medium, and the processor 601 may execute the program instructions to implement functions such as the heterogeneous code translation methods of the various embodiments of this 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 also include an input device 603 and an output device 604, which are interconnected via a bus system and / or other forms of connection mechanism (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. The output device 604 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0147] Of course, for the sake of simplicity, Figure 6 Only some of the components of the electronic device relevant to this application are shown in this illustration; components such as buses, input / output interfaces, etc., are omitted. In addition, the electronic device may include any other suitable components depending on the specific application.

[0148] In addition to the methods and apparatus described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the heterogeneous code translation methods according to various embodiments of this application described above.

[0149] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's electronic device, partially on the user's device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server.

[0150] Furthermore, embodiments of this application may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps in the heterogeneous code translation methods according to various embodiments of this application described above.

[0151] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0152] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0153] The block diagrams of devices, apparatuses, devices, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0154] It should also be noted that in the apparatus, equipment, and methods of this application, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions of this application.

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

[0156] The above description has been given for illustrative and descriptive purposes. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

[0157] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications or equivalent substitutions made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A heterogeneous code transpilation method, wherein, The method includes: Obtain source program heterogeneous code running on a source heterogeneous hardware system. The source heterogeneous hardware system is a system composed of different types of hardware and software and includes at least one of different architectures, operating systems, programming languages ​​or communication protocols. The source program heterogeneous code includes: CUDA code, HIP code or OPENCL code. The source program heterogeneous code is compiled to generate an intermediate representation of the source heterogeneous hardware system, which includes: HSAIL, SPIR-V or PTX. The intermediate representation of the source heterogeneous hardware system is parsed to obtain the corresponding syntax tree and symbol table. The symbol table includes symbol information included in the intermediate representation of the source heterogeneous hardware system. The syntax tree is constructed by parsing the token stream obtained by decomposing the intermediate representation of the source heterogeneous hardware system. One instruction in the intermediate representation corresponds to one token stream. Traverse the syntax tree and symbol table, map the symbol information according to the first preset mapping rule, and generate an LLVM intermediate representation. The first preset mapping rule includes the mapping relationship between the symbol information and the LLVM intermediate representation. The LLVM intermediate representation is mapped to obtain RISC-V extension code, which corresponds to RISC-V extension instructions and is used to run on the target hardware system.

2. The method according to claim 1, wherein, The process of mapping the LLVM intermediate representation to obtain the RISC-V extended code includes: According to the second preset mapping rule, the instructions included in the LLVM intermediate representation are mapped to RISC-V extended instructions. The second preset mapping rule includes the mapping relationship between the instructions included in the LLVM and the RISC-V extended instructions. The RISC-V extension code is constructed based on the RISC-V extension instructions obtained from the mapping.

3. The method according to claim 2, wherein, The mapping relationship includes at least one of the following: The mapping relationship between memory access instructions for the source heterogeneous hardware system and memory access instructions for the target hardware system; The mapping relationship between the instructions for calling parallel computing resources in the synchronization mechanism of the source heterogeneous hardware system and the instructions for calling the smallest parallel unit in the synchronization mechanism of the target hardware system.

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

5. The method according to claim 1, wherein, The target hardware system includes: an embedded hardware system, an Internet of Things (IoT) device, or a network processor.

6. A heterogeneous code translation device, wherein, The device includes: The code acquisition module is configured to acquire source program heterogeneous code running on a source heterogeneous hardware system. The source heterogeneous hardware system is a system composed of different types of hardware and software and includes at least one of different architectures, operating systems, programming languages ​​or communication protocols. The source program heterogeneous code includes: CUDA code, HIP code or OPENCL code. The code compilation module is configured to compile the heterogeneous source code to generate an intermediate representation of the heterogeneous source hardware system, wherein the intermediate representation of the heterogeneous source hardware system includes: HSAIL, SPIR-V or PTX. The first mapping module is configured to parse the intermediate representation of the source heterogeneous hardware system to obtain a corresponding syntax tree and symbol table. The symbol table includes symbol information included in the intermediate representation of the source heterogeneous hardware system. The syntax tree is constructed by parsing the token stream obtained from the decomposition of the intermediate representation of the source heterogeneous hardware system. One instruction in the intermediate representation corresponds to one token stream. The module traverses the syntax tree and symbol table and maps the symbol information according to a first preset mapping rule to generate an LLVM intermediate representation. The first preset mapping rule includes the mapping relationship between the symbol information and the LLVM intermediate representation. The second mapping module is configured to map the LLVM intermediate representation to obtain RISC-V extension code, which corresponds to RISC-V extension instructions and is used to run on the target hardware system.

7. 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 used to implement the method as described in any one of claims 1-5 by running a program in the memory.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method as described in any one of claims 1-5.

9. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, cause the processor to implement the method as described in any one of claims 1-5.

Images