Operator hybrid compilation methods, apparatus, electronic devices, storage media, and programs

Abstract

This invention discloses a method, apparatus, electronic device, storage medium, and program for operator hybrid compilation. The method includes: obtaining a first original operator code file of a first hardware instruction execution model and a second original operator code file of a second hardware instruction execution model; wherein a function call relationship exists between the first and second original operator code files; compiling the first and second original operator code files to obtain a first virtual instruction file and a second virtual instruction file; and linking and compiling the first and second virtual instruction files using a virtual instruction compiler to obtain an executable file of hardware instructions. The technical solution of this invention can improve the compatibility of operator hybrid compilation, reduce the maintenance difficulty of operators, simplify the underlying hardware scheduling and optimization logic, and enhance the versatility and stability of hardware resource utilization.

Description

Technical Field

[0001] The embodiments of the present invention relate to the fields of computer applications and artificial intelligence, and in particular to an operator hybrid compilation method, apparatus, electronic device, storage medium and program. Background Technology

[0002] Currently, GPGPU (General-Purpose computing on Graphics Processing Units) and DSA (Digital Signal Array chip) type chips employ various hardware instruction execution models, such as SIMT (Single Instruction Multiple Threads) and SIMD (Single Instruction Multiple Data).

[0003] However, the software ecosystems of different hardware instruction execution models, including operator libraries and compilers, are difficult to share and be compatible with. For example, the types in the SIMT hardware instruction execution model are typically scalars, describing the computational logic of a single thread and automatically extending scalar operations to the entire thread bundle. The types in the SIMD hardware instruction execution model include scalars and vectors, directly describing the computational logic of the entire thread bundle. The operator libraries and compilers for different hardware instruction execution models are independent. Therefore, how to solve the difficulties of different software ecosystems for different hardware instruction execution models, and enable their software ecosystems to coexist on the same hardware architecture, is a pressing issue that needs to be addressed. Summary of the Invention

[0004] This invention provides a method, apparatus, electronic device, storage medium, and program for hybrid operator compilation, which can improve the compatibility of hybrid operator compilation, reduce the maintenance difficulty of operators, simplify the underlying hardware scheduling and optimization logic, and enhance the versatility and stability of hardware resource utilization.

[0005] According to one aspect of the present invention, an operator hybrid compilation method is provided, comprising: Obtain the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; The first original operator code file and the second original operator code file are compiled to obtain a first virtual instruction file and a second virtual instruction file; The first virtual instruction file and the second virtual instruction file are linked and compiled by a virtual instruction compiler to obtain an executable file of hardware instructions.

[0006] According to another aspect of the present invention, an operator hybrid compilation apparatus is provided, comprising: The original operator code file acquisition module is used to acquire the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; The original operator code file compilation module is used to compile the first original operator code file and the second original operator code file to obtain the first virtual instruction file and the second virtual instruction file; The executable file processing module is used to link and compile the first virtual instruction file and the second virtual instruction file through a virtual instruction compiler to obtain an executable file of hardware instructions.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute the operator hybrid compilation method according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the operator hybrid compilation method according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the operator hybrid compilation method described in any embodiment of the present invention.

[0010] This invention, through obtaining a first original operator code file of a first hardware instruction execution model and a second original operator code file of a second hardware instruction execution model that has a function call relationship with the first original operator code file, compiles the first and second original operator code files to obtain a first virtual instruction file and a second virtual instruction file. Finally, a virtual instruction compiler links and compiles the first and second virtual instruction files to obtain an executable file of hardware instructions. This realizes a mixed compilation process of operators from different hardware instruction execution models, solves the problem of difficulty in sharing and compatibility of operators from different hardware instruction execution models, improves the compatibility of mixed operator compilation, reduces the maintenance difficulty of operators, simplifies the underlying hardware scheduling and optimization logic, and enhances the versatility and stability of hardware resource utilization.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of an operator hybrid compilation method provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of an operator hybrid compilation method provided in Embodiment 2 of the present invention; Figure 3 This is a schematic diagram illustrating the effect of mutual calling between SIMT code files and SIMD code files provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a process for hybrid compilation of SIMT and SIMD operators provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of an operator hybrid compilation device provided in Embodiment 3 of the present invention; Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

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

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of an operator hybrid compilation method provided in Embodiment 1 of the present invention. This embodiment is applicable to the hybrid compilation of operators with different hardware instruction execution models. The method can be executed by an operator hybrid compilation device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. This electronic device can be a terminal device or a server device, as long as it can execute the operator hybrid compilation method. The present invention does not limit the specific type of electronic device. Correspondingly, as... Figure 1 As shown, the method includes the following operations: S110. Obtain the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file.

[0017] The hardware instruction execution model refers to the complete mechanism by which computer hardware works collaboratively from the low-level physical layer (such as transistors and logic gates) to the system architecture layer (such as CPU and memory) to fetch, decode, and execute program instructions. The hardware instruction execution model defines the lifecycle of instructions in the hardware, resource usage, and parallel processing capabilities. The first hardware instruction execution model and the second hardware instruction execution model can be two different types of hardware instruction execution models. For example, the first hardware instruction execution model can be SIMT, and the second hardware instruction execution model can be SIMD. Alternatively, the first hardware instruction execution model can be SIMD, and the second hardware instruction execution model can be SIMT. This embodiment of the invention does not limit the specific types of the first and second hardware instruction execution models.

[0018] The first original operator code file can be a code file independently compiled by a compiler for a first hardware instruction execution model, and the second original operator code file can be a code file independently compiled by a compiler for a second hardware instruction execution model. Both the first and second original operator code files can include device-side functions. Device-side functions are a relative concept to host-side functions. For example, host-side functions can be functions running on the CPU (Central Processing Unit) side, while device-side functions can be functions running on the GPU (Graphics Processing Unit) side or the NPU (Neural Network Processing Unit). For example, when the first hardware instruction execution model is SIMT, the first original operator code file can be a SIMT code file; when the second hardware instruction execution model is SIMD, the second original operator code file can be a SIMD code file.

[0019] In an environment where both a first hardware instruction execution model and a second hardware instruction execution model coexist, to reduce the strong dependence of various operators on hardware instruction sets and hardware architectures, and to adapt to multiple generations of hardware and multi-vendor hardware platforms, target operators in the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model, which has function call relationships with the first original operator code file, can be mixed-compiled. The target operator can be an operator with the same function in both the first and second original operator code files. Before mixing-compiling the target operator, the first and second original operator code files with function call relationships can be obtained first.

[0020] S120. Compile the first original operator code file and the second original operator code file to obtain the first virtual instruction file and the second virtual instruction file.

[0021] The first virtual instruction file can be a virtual instruction file obtained by compiling the first original operator code file. The second virtual instruction file can be a virtual instruction file obtained by compiling the second original operator code file. The virtual instruction file can be a file composed of virtual instruction sets, and the virtual instructions are not directly executed by physical hardware such as the CPU.

[0022] Accordingly, after obtaining the first and second original operator code files, they can be compiled using appropriate compilers to obtain the first and second virtual instruction files, respectively. For example, assuming the first virtual instruction file is a SIMT code file, it can be compiled using a SIMT compiler to obtain the first virtual instruction file. Similarly, assuming the second virtual instruction file is a SIMD code file, it can be compiled using a SIMD compiler to obtain the second virtual instruction file.

[0023] The first and second virtual instruction files can be virtual instruction files with a unified instruction set model. That is, the first and second virtual instruction files do not distinguish between the first and second hardware instruction execution models; both vectors and scalars in the original operator code files are explicitly marked. Therefore, the first and second virtual instruction files can use a unified mapping rule to functionally map operators from different software ecosystems, thereby mapping operators with the same data processing functions from different software ecosystems to a unified virtual instruction set. This unified virtual instruction set enables an abstract description of operator functions, effectively shielding the differences in software ecosystems between the first and second original operator code files.

[0024] S130. The first virtual instruction file and the second virtual instruction file are linked and compiled by a virtual instruction compiler to obtain an executable file of hardware instructions.

[0025] Among them, a virtual instruction compiler is a compiler that compiles high-level programming languages ​​or intermediate representations into virtual instruction sets (also known as bytecode or intermediate instructions).

[0026] After generating the first and second virtual instruction files, they are further input into a virtual instruction compiler. The compiler performs linking, merging, and compilation operations on the first and second virtual instruction files to generate hardware instructions based on the virtual instruction set, resulting in an executable file of the hardware instructions. This process allows the code in the first and second primitive operator code files to call each other.

[0027] As is understandable, executable files containing hardware instructions typically include machine instructions. The compiler translates high-level languages ​​(such as C / C++) or assembly language into binary instructions (i.e., hardware instructions) that the processor can directly execute. When an executable file is run, the operating system loads it into memory and jumps to the entry point to begin executing instructions. The executable file's header describes the layout of the code segment, data segment, and stack in memory, ensuring correct program loading. When an executable file is specifically designed to directly manipulate hardware (such as embedded systems and drivers), it can directly control and modify hardware registers to control peripherals through memory-mapped I / O (MMIO) or dedicated instructions. In bare-metal systems, executable files start directly from the reset vector, independent of the operating system, and have complete control over hardware resources.

[0028] Therefore, the above-described operator hybrid compilation method can ensure that functions in the second original operator code file, conforming to the calling rules of the first hardware instruction execution model, are used by functions in the first original operator code file. Conversely, functions in the first original operator code file, conforming to the calling rules of the second hardware instruction execution model, can be used by functions in the second original operator code file. Thus, operators from different software ecosystems with the same data processing capabilities do not need to be compiled separately; they can be written using only one method as needed. This allows for partial code sharing among compilers, reducing the workload of maintaining operator libraries and other software ecosystems, and simplifying operator maintenance.

[0029] At the hardware level, after unified encapsulation through hybrid compilation of operators, the upper-layer operator logic is decoupled from the lower-layer hardware instructions. This eliminates the need for customizing operators for different chip architectures and instruction set versions, improving migration compatibility across various hardware platforms such as CPUs, GPUs, and NPUs. The same set of operator logic can be adapted to different iterations of the same hardware series and similar acceleration hardware from different manufacturers through hybrid compilation, reducing operator refactoring work caused by hardware upgrades or platform switching. Hybrid compilation of operators can uniformly handle low-level optimizations such as hardware parallelism, memory access, and pipelining. The hardware side does not need to maintain a large number of customized operators, reducing the adaptation costs between hardware drivers, runtime libraries, and operators. A unified compilation path can also generate code more adapted to hardware execution units, reducing hardware execution conflicts, memory access anomalies, and fluctuations in computing power utilization caused by operator differences, ensuring stable execution across different hardware. For edge and embedded hardware, the above-mentioned operator hybrid compilation method can reduce the need for dedicated operator units, reduce the complexity of hardware logic design and verification costs, and improve the versatility of hardware in multiple scenarios.

[0030] This invention, through obtaining a first original operator code file of a first hardware instruction execution model and a second original operator code file of a second hardware instruction execution model that has a function call relationship with the first original operator code file, compiles the first and second original operator code files to obtain a first virtual instruction file and a second virtual instruction file. Finally, a virtual instruction compiler links and compiles the first and second virtual instruction files to obtain an executable file of hardware instructions. This realizes a mixed compilation process of operators from different hardware instruction execution models, solves the problem of difficulty in sharing and compatibility of operators from different hardware instruction execution models, improves the compatibility of mixed operator compilation, reduces the maintenance difficulty of operators, simplifies the underlying hardware scheduling and optimization logic, and enhances the versatility and stability of hardware resource utilization.

[0031] Example 2 Figure 2 This is a flowchart of an operator hybrid compilation method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and is further specified. In this embodiment, various specific optional implementation methods are given for compiling the first original operator code file and the second original operator code file, and for linking and compiling the first virtual instruction file and the second virtual instruction file through a virtual instruction compiler. Correspondingly, as Figure 2 As shown, the method in this embodiment may include: S210. Obtain the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model.

[0032] There is a function call relationship between the first original operator code file and the second original operator code file.

[0033] S220. Determine the type mapping rules for function variables; wherein, the type mapping rules for function variables include scalar mapping rules and vector mapping rules.

[0034] Among them, type mapping rules can be used to determine the specific mapping method of function variables on the virtual instruction set. Scalar mapping rules can be used to determine the specific mapping method of function variables in scalar form on the virtual instruction set. Vector mapping rules can be used to determine the specific mapping method of function variables in vector form on the virtual instruction set.

[0035] Since function variables typically include both scalar and vector parameters, type mapping rules can be configured for scalar and vector parameters respectively.

[0036] S230. The target function parameters in the first original operator code file and / or the second original operator code file are mapped according to the type mapping rules of the function variables to obtain the first virtual instruction file and the second virtual instruction file.

[0037] The target function parameters can be parameters from functions that need to be called across files in the first and / or second original operator code files.

[0038] Understandably, before performing mixed compilation of operators, it's advisable to configure type mapping rules for different function variables. These type mapping rules can further distinguish between scalar mapping rules and vector mapping rules. Using scalar mapping rules maps the scalars corresponding to function variables to the types in the corresponding virtual instruction set; using vector mapping rules maps the vectors corresponding to function variables to the types in the corresponding virtual instruction set.

[0039] Accordingly, after obtaining the first and second original operator code files, the functions that need to be called across files in the first and / or second original operator code files can be identified and used as target functions. The parameters involved in the target functions are then mapped as target function parameters. Different types of target function parameters require different type mapping rules. After completing the mapping of the target function parameters in the first and / or second original operator code files, the first virtual instruction file corresponding to the first original operator code file and the second virtual instruction file corresponding to the second original operator code file can be obtained.

[0040] Specifically, when the objective function parameters are scalar parameters, scalar mapping rules can be used to map the objective function parameters; when the objective function parameters are vector parameters, vector mapping rules can be used to map the objective function parameters.

[0041] In an optional embodiment of the present invention, the mapping process of the target function parameters in the first original operator code file and / or the second original operator code file according to the type mapping rule of the function variable may include: if the target function parameter is determined to be a scalar parameter, mapping the target function parameter to a first target mapping parameter of a first target data type, and storing the first target mapping parameter in a virtual scalar register; if the target function parameter is determined to be a vector parameter, mapping the target function parameter to a second target mapping parameter of a second target data type, and storing the second target mapping parameter in a virtual vector register.

[0042] The first target data type can be one type of data type, and the second target data type can be another type of data type. Optionally, the first target data type and the second target data type can be the same or different, and this embodiment of the invention does not limit this. The first target mapping parameter can be a parameter mapped from a scalar parameter, and the second target mapping parameter can be a parameter mapped from a vector parameter. The virtual register can be a temporary variable in the intermediate representation; it is not a real hardware register, but an abstract identifier used internally by the compiler. Accordingly, the virtual scalar register can be a virtual register in scalar form; the virtual vector register can be a virtual register in vector form.

[0043] Regardless of whether it's the first or second original operator code file, as long as the original operator code file includes the target function parameters that need to be mapped, the corresponding mapping rules can be used for mapping processing. Specifically, when mapping the target function parameters in the first and / or second original operator code files according to the function variable type mapping rules, if the target function parameter is a scalar parameter, it can be mapped to a first target mapping parameter of the first target data type, and the first target mapping parameter is stored in a virtual scalar register. If the target function parameter is a vector parameter, it can be mapped to a second target mapping parameter of the second target data type, and the second target mapping parameter is stored in a virtual vector register.

[0044] For example, in a virtual instruction file, suppose a virtual instruction is ".ureg .A a". This virtual instruction indicates that the variable 'a' is mapped to a data type 'A', and the mapped data type 'A' is stored in the ureg register. Optionally, 'A' can represent any data type, such as u32. The type of the ureg register can be determined based on the type of 'A'. For example, when the virtual instruction is ".ureg .u32 a", it can indicate that the variable 'a' is mapped to a data type 'u32', and the mapped data type 'u32' is stored in the 32-bit UREG (Uniform Register) register.

[0045] For example, in a virtual instruction file, suppose a virtual instruction is ".vreg .B b". This virtual instruction indicates that the variable b is mapped to a data type B, and the mapped data type B is stored in the vector register of vreg. Optionally, B can represent any data type, such as u32. For example, when the virtual instruction is ".vreg .u32b", it can indicate that the variable b is mapped to a data type u32, and the mapped data type u32 is stored in the vector register of VREG (Vector Register).

[0046] For example, let's illustrate the type mapping rules for different types of function variables using SIMD and SIMT code files. In a SIMD function within a SIMD code file, a `__vector int` represents a fixed-length signed 32-bit integer. Variables of this type are compiled and mapped by the SIMD compiler to the ".vreg .s32" virtual vector register, while `int` is compiled to the ".ureg .s32" virtual scalar register. In a SIMT function within a SIMT code file, the SIMT compiler analyzes whether each variable has the same value across all threads within the thread bundle. If they do, the `int` variable is mapped to the ".ureg .s32" virtual scalar register; otherwise, it is compiled to the ".vreg .s32" virtual vector register. The type mapping rules for other types of function variables are similar; `__vector float` is compiled and mapped to the ".vreg .f32" virtual vector register in the SIMD compiler. In the SIMD compiler, `float` is compiled and mapped to a virtual scalar register in the ".ureg .f32" format. In the SIMT compiler, based on the analysis results, `float` can be compiled and mapped to either a virtual vector register in the ".vreg .f32" format or a virtual scalar register in the ".ureg .f32" format. Therefore, the two virtual instruction files generated in the final mapping do not distinguish between SIMD and SIMT, effectively masking the differences in the software ecosystems of SIMD and SIMT.

[0047] In an optional embodiment of the present invention, while compiling the first original operator code file and the second original operator code file, the method may further include: determining the target monitoring variable in the first original operator code file and / or the second original operator code file; and monitoring the consistency information of the target monitoring variable within the thread bundle in real time; wherein the consistency information of the target monitoring variable within the thread bundle is used as reference information for mapping processing.

[0048] Among them, the target monitoring variable can be a variable that needs to be monitored in real time.

[0049] In some types of hardware instruction execution models, a variable in a code file may represent multiple meanings. For example, in SIMT code, `int` can simultaneously represent a vector and a scalar. That is, in SIMT code, the same line of code "int a" may represent a scalar or a vector in hardware, determined by the SIMT hardware execution model. Therefore, while compiling the first and second primitive operator code files, variables that can represent different meanings in the first and / or second primitive operator code files can be used as target monitoring variables. The hardware instruction execution model monitors, analyzes, and records the consistency information of the target monitoring variables within the thread bundle in real time. This consistency information is used as reference information to determine the specific type mapping rules during mapping processing.

[0050] For example, assuming the second original operator code file is a SIMT code file, when SIMT compiles the second original operator code file, it needs to analyze in real time whether the int variables in the second original operator code file represent scalar parameters or vector parameters. If SIMT determines that the int variable in line 3 of the second original operator code file represents a scalar parameter, it can use scalar mapping rules for alignment and mapping; if SIMT determines that the int variable in line 9 of the second original operator code file represents a vector parameter, it can use vector mapping rules for alignment and mapping.

[0051] In an optional embodiment of the present invention, before linking and compiling the first virtual instruction file and the second virtual instruction file by the virtual instruction compiler, the method may further include: determining the target called functions that have a call relationship in the first virtual instruction file and the second virtual instruction file; adjusting the function naming rules of the target called functions in the first virtual instruction file and the second virtual instruction file so that the function names of the target called functions are consistent in the first virtual instruction file and the second virtual instruction file.

[0052] The target function to be called can be any function that is being called.

[0053] Since the first and second original operator code files are compiled separately, and the first and second hardware instruction execution models differ at the programming level (e.g., the parameter types of SIMT and SIMD are different at the C language level), after obtaining the first and second virtual instruction files, to ensure successful compilation, the target called functions with call relationships in the first and second virtual instruction files can be reviewed and adjusted. This mainly involves adjusting the function naming rules of the target called functions to ensure consistency in function names between the first and second virtual instruction files, allowing the declarations and definitions of the same functions to be mutually searchable.

[0054] S240. Link the target calling function and the target called function in the first virtual instruction file and the second virtual instruction file.

[0055] S250, Complete the function content of the target called function in the virtual instruction file.

[0056] S260. Input the first virtual instruction file and the second virtual instruction file into the virtual instruction compiler, and compile them into hardware instructions through the virtual instruction compiler to obtain the executable file of the hardware instructions.

[0057] The target calling function can be a function that needs to call the target called function. Optionally, the target calling function can exist in a first virtual instruction file and / or a second virtual instruction file, and the target called function can also exist in the first virtual instruction file and / or the second virtual instruction file. The first virtual instruction file may include the target calling function and / or the target calling function, and the second virtual instruction file may also include the target calling function and / or the target calling function. A set of target calling functions and target called functions with a calling relationship exist in the first virtual instruction file and the second virtual instruction file, respectively.

[0058] Specifically, when linking and compiling the first and second virtual instruction files using a virtual instruction compiler, the target calling function and the target called function in the first and / or second virtual instruction files can be linked first. For example, the first virtual instruction file may include a target calling function A, and the second virtual instruction file may include a target called function B. If target calling function A needs to call target called function B, then the linking relationship of target called function B can be established at the target calling function in the first virtual instruction file. Furthermore, the function content of the target called function in the virtual instruction file can be completed. The completion process may include, but is not limited to, checking whether the target called function meets the function call requirements and checking for errors in the function content of the target called function in the virtual instruction file. Finally, the first and second virtual instruction files with linking information can be input into the virtual instruction compiler, which will then compile them into hardware instructions to obtain the executable file of the hardware instructions.

[0059] In an optional embodiment of the present invention, linking the target calling function and the target called function in the first virtual instruction file and the second virtual instruction file may include: adding a link marker for the target called function at the target calling function; the link marker is used to indicate that the virtual instruction file needs to call the target called function; or, copying the function code block of the target called function to the virtual instruction file where the target calling function is located.

[0060] Optionally, several linking methods can be used to link the target calling function and the target called function in the first and second virtual instruction files. The first option is to add a linker mark for the target called function at the target calling function location. This marker can be a symbol identifier or relocation information, indicating that the virtual instruction file needs to call the target called function. In this method, the linker does not copy the code; it only records information such as the function name, the file where the function resides, and the call address, which needs to be filled in later. The linker then correctly fills in the call address during the linking phase or the loader during the runtime phase. The second option is to directly copy the function code block of the target called function to the virtual instruction file where the target calling function resides. This linking method is equivalent to physically copying the binary instructions of the target called function to the target calling function; the target called function does not need to be searched again at runtime, and there are no external dependencies.

[0061] The above technical solution, after obtaining the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model, determines the type mapping rules such as scalar mapping rules and vector mapping rules for function variables. Based on these type mapping rules, the target function parameters in the first and / or second original operator code files are mapped to obtain the first virtual instruction file corresponding to the first original operator code file and the second virtual instruction file corresponding to the second original operator code file. Furthermore, the generated first and second virtual instruction files are linked and compiled using a virtual instruction compiler to obtain the executable file of the hardware instructions. In summary, the above operator hybrid compilation method can improve the compatibility of operator hybrid compilation, reduce the maintenance difficulty of operators, simplify the underlying hardware scheduling and optimization logic, and enhance the versatility and stability of hardware resource utilization.

[0062] Specific application scenarios To more clearly illustrate the technical solutions provided by the embodiments of the present invention, the embodiments of the present invention take SIMT and SIMD hardware instruction execution models as examples to specifically explain the implementation process of the operator hybrid compilation method. Figure 3 This is a schematic diagram illustrating the effect of mutual calling between SIMT code files and SIMD code files provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the process of hybrid compilation of SIMT and SIMD operators provided by an embodiment of the present invention. In a specific example, taking the example of how to call a SIMD device-side function from a SIMT code file, the method supporting hybrid compilation of SIMD and SIMT operators can include the following operations: Step 1: First, obtain the SIMT code file and SIMD code file that have a calling relationship.

[0063] For example, the SIMT code file can be named simt.cc, and the SIMD code file can be named simd.cc. The contents of the two code files are as follows: SIMT code file simt.cc: / / Declaration of the simd function __device__ int simd_add(int a, int b); / / Calling simd functions in simt __device__ int simt_add(int a, int b) { return simd_add(a, b); } SIMD code file simd.cc: / / Definition of the simd function __device__ __vector int simd_add(__vector int a, __vector int b) { return a + b; } Step 2: Compile the SIMT code file and SIMD code file using their respective compilers to obtain the corresponding virtual instruction files.

[0064] The SIMT code file simt.cc is compiled by the SIMT compiler to obtain the SIMT virtual instruction file.

[0065] Specifically, the declaration of the "simd_add" function in the first line of the SIMT code file corresponds to the following information in the compiled virtual instruction file: .extern .func (.param .vreg .s32 __ret_0) simd_add_iii( .param .vreg .s32 __param_0, .param .vreg .s32 __param_1, ) Here, ".extern" indicates that the function definition is in another file, ".func" indicates that it is a device function, "simd_add_iii" is the function name, and the corresponding definition can be found by this name and the attributes of the parameter `param`, and ".veg" indicates that the parameter should be passed in a vector register. Optionally, ".vreg" and ".ureg" are chosen by the compiler according to the actual intent of the code.

[0066] The definition of the "simt_add" function on the second line of the SIMT code file corresponds to the following information in the compiled virtual instruction file: .visible .func (.param .veg .s32 __ret_0) simt_add_iii( .param .vreg .s32 __param_0, .param .vreg .s32 __param_1, ) { … … … / / Call simd_add from simt here call simd_add_iii, %r3, %r2, %r1; … … … exit; } The SIMD code file simd.cc is compiled by the SIMD compiler to obtain the SIMD virtual instruction file.

[0067] Specifically, the information in the virtual instruction file corresponding to the compiled SIMD code file is as follows: .visible .func (.param .vreg .s32 __ret_0) simd_add_iii( .param .vreg .s32 __param_0, .param .vreg .s32 __param_1, ) { … … … add.s32 %r3, %r2, %r1; … … … exit; } The ".visible" part indicates that the function definition is visible in this file.

[0068] In the aforementioned virtual instruction file, ".param .vreg .s32 __param_0" indicates that parameter param_0 is mapped to data of type s32, and the mapped s32 data is stored in the vector register. ".param .vreg .s32__param_1" indicates that parameter param_1 is mapped to data of type s32, and the mapped s32 data is stored in the vector register. %r3 represents variable c, %r2 represents variable a, and %r1 represents variable b. Where c = a + b.

[0069] Step 3: Input the two virtual instruction files generated during compilation into the virtual instruction compiler for linking and compilation to obtain the executable file of the hardware instructions.

[0070] Specifically, the virtual instruction compiler will search globally for the definition of the "simd_add" function in the line "callsimd_add_iii, %r3, %r2, %r1;" in the virtual instruction file corresponding to the SIMT code file, and leave the link symbol.

[0071] The above process allows SIMT and SIMD code to call each other.

[0072] Therefore, the above method for supporting the mixed compilation of SIMD and SIMT operators can achieve the following effects: A SIMD function: __device__ __vector int simd_add(__vector int a, __vector int b) { return a + b; } The simd function can be called within SIMT code: That is, first declare the simd function in the SIMT code: `__device__ int simd_add(int a, int b)`. Then you can call the simd function in the SIMT code. __device__ int simt_add(int a, int b) { return simd_add(a, b); } Correspondingly, if a target operator already exists written in SIMD, it is not necessary to rewrite the target operator using the SIMD method when it needs to be integrated into a SIMT-style operator.

[0073] The aforementioned method for supporting mixed compilation of SIMD and SIMT operators first requires establishing a type mapping relationship to distinguish whether the parameter types in the virtual instructions generated from the code files of different hardware instruction execution models refer to scalars or vectors. The code files of the two hardware instruction execution models are compiled separately onto a unified virtual instruction set. In this virtual instruction set, SIMT and SIMD are not distinguished; vectors and scalars are explicitly marked. Subsequently, the virtual instructions of the two hardware instruction execution models are linked and compiled again to generate the corresponding hardware instructions.

[0074] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0075] It should be noted that any arrangement or combination of the technical features in the above embodiments also falls within the protection scope of this invention.

[0076] Example 3 Figure 5 This is a schematic diagram of an operator hybrid compilation device provided in Embodiment 3 of the present invention, as shown below. Figure 5 As shown, the device includes: a raw operator code file acquisition module 510, a raw operator code file compilation module 520, and an executable file processing module 530, wherein: The original operator code file acquisition module 510 is used to acquire the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; The original operator code file compilation module 520 is used to compile the first original operator code file and the second original operator code file to obtain a first virtual instruction file and a second virtual instruction file; The executable file processing module 530 is used to link and compile the first virtual instruction file and the second virtual instruction file through a virtual instruction compiler to obtain an executable file of hardware instructions.

[0077] This invention, through obtaining a first original operator code file of a first hardware instruction execution model and a second original operator code file of a second hardware instruction execution model that has a function call relationship with the first original operator code file, compiles the first and second original operator code files to obtain a first virtual instruction file and a second virtual instruction file. Finally, a virtual instruction compiler links and compiles the first and second virtual instruction files to obtain an executable file of hardware instructions. This realizes a mixed compilation process of operators from different hardware instruction execution models, solves the problem of difficulty in sharing and compatibility of operators from different hardware instruction execution models, improves the compatibility of mixed operator compilation, reduces the maintenance difficulty of operators, simplifies the underlying hardware scheduling and optimization logic, and enhances the versatility and stability of hardware resource utilization.

[0078] Optionally, the original operator code file compilation module 520 is further configured to: determine the type mapping rules for function variables; wherein the type mapping rules for function variables include scalar mapping rules and vector mapping rules; and perform mapping processing on the target function parameters in the first original operator code file and / or the second original operator code file according to the type mapping rules for function variables to obtain the first virtual instruction file and the second virtual instruction file.

[0079] Optionally, the original operator code file compilation module 520 is further configured to: when the objective function parameter is determined to be a scalar parameter, map the objective function parameter to a first objective mapping parameter of a first objective data type, and store the first objective mapping parameter in a virtual scalar register; when the objective function parameter is determined to be a vector parameter, map the objective function parameter to a second objective mapping parameter of a second objective data type, and store the second objective mapping parameter in a virtual vector register.

[0080] Optionally, the original operator code file compilation module 520 is further configured to: determine the target monitoring variable in the first original operator code file and / or the second original operator code file; monitor the consistency information of the target monitoring variable within the thread bundle in real time; wherein the consistency information of the target monitoring variable within the thread bundle is used as reference information for mapping processing.

[0081] Optionally, the above apparatus further includes a virtual instruction file adjustment module, configured to: determine target called functions that have a calling relationship in the first virtual instruction file and the second virtual instruction file; and adjust the function naming rules of the target called functions in the first virtual instruction file and the second virtual instruction file so that the function names of the target called functions are consistent in the first virtual instruction file and the second virtual instruction file.

[0082] Optionally, the executable file processing module 530 is further configured to: link the target calling function and the target called function in the first virtual instruction file and / or the second virtual instruction file; complete the function content of the target called function in the virtual instruction file; input the first virtual instruction file and the second virtual instruction file to the virtual instruction compiler, and compile them into hardware instructions through the virtual instruction compiler to obtain the executable file of the hardware instructions.

[0083] Optionally, the executable file processing module 530 is further configured to: add a link marker for the target called function at the target calling function; the link marker is used to indicate that the virtual instruction file needs to call the target called function; or, copy the function code block of the target called function to the virtual instruction file where the target calling function is located.

[0084] The above-described operator hybrid compilation apparatus can execute the operator hybrid compilation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in this embodiment can be found in the operator hybrid compilation method provided in any embodiment of the present invention.

[0085] Since the operator hybrid compilation apparatus described above is an apparatus capable of executing the operator hybrid compilation method in the embodiments of the present invention, those skilled in the art can understand the specific implementation and various variations of the operator hybrid compilation apparatus of this embodiment based on the operator hybrid compilation method described in the embodiments of the present invention. Therefore, how the operator hybrid compilation apparatus implements the operator hybrid compilation method in the embodiments of the present invention will not be described in detail here. Any apparatus used by those skilled in the art to implement the operator hybrid compilation method in the embodiments of the present invention falls within the scope of protection of this application.

[0086] Example 4 Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0087] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0088] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0089] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as operator hybrid compilation methods.

[0090] Optionally, the operator hybrid compilation method may include: obtaining a first original operator code file of a first hardware instruction execution model and a second original operator code file of a second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; compiling the first original operator code file and the second original operator code file to obtain a first virtual instruction file and a second virtual instruction file; and linking and compiling the first virtual instruction file and the second virtual instruction file using a virtual instruction compiler to obtain an executable file of hardware instructions.

[0091] In some embodiments, the operator hybrid compilation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the operator hybrid compilation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the operator hybrid compilation method by any other suitable means (e.g., by means of firmware).

[0092] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0093] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0094] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer 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.

[0095] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0096] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0097] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0098] This invention also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the operator hybrid compilation method provided in any embodiment of this invention. This program product shares the same inventive concept as the operator hybrid compilation method disclosed in the embodiments of this invention, and therefore will not be described further here.

[0099] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0100] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A hybrid operator compilation method, characterized in that, include: Obtain the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; The first original operator code file and the second original operator code file are compiled to obtain a first virtual instruction file and a second virtual instruction file; The first virtual instruction file and the second virtual instruction file are linked and compiled by a virtual instruction compiler to obtain an executable file of hardware instructions.

2. The method according to claim 1, characterized in that, The step of compiling the first original operator code file and the second original operator code file to obtain the first virtual instruction file and the second virtual instruction file includes: Determine the type mapping rules for function variables; wherein, the type mapping rules for function variables include scalar mapping rules and vector mapping rules; The target function parameters in the first original operator code file and / or the second original operator code file are mapped according to the type mapping rules of the function variables to obtain the first virtual instruction file and the second virtual instruction file.

3. The method according to claim 2, characterized in that, The mapping process for the target function parameters in the first original operator code file and / or the second original operator code file according to the type mapping rule of the function variables includes: If the objective function parameter is determined to be a scalar parameter, the objective function parameter is mapped to a first objective mapping parameter of a first objective data type, and the first objective mapping parameter is stored in a virtual scalar register; If the objective function parameter is determined to be a vector parameter, the objective function parameter is mapped to a second objective mapping parameter of a second objective data type, and the second objective mapping parameter is stored in a virtual vector register.

4. The method according to claim 2 or 3, characterized in that, The compilation process, which includes compiling the first and second original operator code files, also includes: Determine the target monitoring variables in the first raw operator code file and / or the second raw operator code file; Real-time monitoring of the consistency information of the target monitoring variable within the thread bundle; The consistency information of the target monitoring variable within the thread bundle is used as reference information for mapping processing.

5. The method according to claim 1, characterized in that, Before linking and compiling the first virtual instruction file and the second virtual instruction file using the virtual instruction compiler, the method further includes: Identify the target called functions that have a call relationship in the first virtual instruction file and the second virtual instruction file; The naming rules for the target called function in the first virtual instruction file and the second virtual instruction file are adjusted to ensure that the function name of the target called function remains consistent in both the first virtual instruction file and the second virtual instruction file.

6. The method according to claim 5, characterized in that, The step of linking and compiling the first virtual instruction file and the second virtual instruction file using a virtual instruction compiler to obtain an executable file of hardware instructions includes: Link the target calling function and the target called function in the first virtual instruction file and / or the second virtual instruction file; The function content of the target called function in the virtual instruction file is completed; The first virtual instruction file and the second virtual instruction file are input into the virtual instruction compiler, which compiles them into hardware instructions to obtain the executable file of the hardware instructions.

7. The method according to claim 6, characterized in that, The linking of the target calling function and the target called function in the first virtual instruction file and the second virtual instruction file includes: Add a link marker to the target called function at the target calling function location; the link marker indicates that the virtual instruction file needs to call the target called function; or Copy the function code block of the target called function to the virtual instruction file where the target calling function is located.

8. An operator hybrid compiler apparatus, characterized in that, include: The original operator code file acquisition module is used to acquire the first original operator code file of the first hardware instruction execution model and the second original operator code file of the second hardware instruction execution model; wherein, there is a function call relationship between the first original operator code file and the second original operator code file; The original operator code file compilation module is used to compile the first original operator code file and the second original operator code file to obtain the first virtual instruction file and the second virtual instruction file; The executable file processing module is used to link and compile the first virtual instruction file and the second virtual instruction file through a virtual instruction compiler to obtain an executable file of hardware instructions.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor, such that the at least one processor is able to perform the operator hybrid compilation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the operator hybrid compilation method according to any one of claims 1-7.

11. A computer program product, characterized in that, It includes a computer program / instruction, wherein the computer program / instruction, when executed by a processor, implements the operator hybrid compilation method of any one of claims 1-7.

Images