Extension method, device and equipment of compiler hardware backend and readable storage medium

Abstract

The application relates to the technical field of computers and discloses an extension method and device for a compiler hardware backend, equipment and a readable storage medium. The compiler comprises a shared deployer, a dynamic loader and a plurality of interface adapters, the method comprises the following steps: obtaining preset runtime libraries and preset operator libraries corresponding to various processors; compiling the preset runtime libraries, the preset operator libraries and the interface adapters corresponding to the various processors to generate target hardware libraries corresponding to the various processors; loading any target hardware library through the dynamic loader; and determining a task deployment position of the shared deployer based on the type of the target hardware library. Through implementation of the technical scheme of the application, the coupling degree of hardware extension and the compiler is reduced, repetitive work in code development, compilation and version maintenance is reduced, and the compiler can quickly support and take various processors as needed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to an extension method, apparatus, device, and readable storage medium for a compiler hardware backend. Background Technology

[0002] In the field of artificial intelligence, there are currently many deep learning frameworks available for model training, such as TensorFlow, PyTorch, and MxNet. However, regardless of the deep learning framework, trained models need to be deployed to real-world applications. Consequently, the variety of devices available for model deployment is constantly expanding with the innovation of AI processors, including CPUs, GPUs, MLUs, and FPGAs from different hardware manufacturers. The continuous diversification of deep learning frameworks and AI processors has led to many-to-many mapping problems, driving the development of AI compilers.

[0003] Taking the mainstream open-source AI compiler TVM (Tensor Virtual Machine) as an example, its front-end performs model parsing and has already achieved integration with common deep learning frameworks, while its back-end handles model deployment. Supported intelligent processors include CPUs and GPUs from different hardware manufacturers. In practical applications, the TVM hardware back-end can be expanded by developing the source code of the TVM back-end and adding deployment modules for new artificial intelligence processors.

[0004] However, when it is necessary to support multiple new types of AI processors, the TVM source code needs to be developed and compiled for each new type of AI processor. The development involves multiple languages ​​and multiple modules, which are widely distributed. A lot of repetitive development will increase the workload. In addition, the backend expansion of the new AI processor is highly coupled with the TVM source code. When the TVM version is updated, the version maintenance workload will also increase with the number of new AI processor device types. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a method, apparatus, device, and readable storage medium for extending the hardware backend of a compiler, in order to solve the problems of high coupling between current hardware extensions and AI compiler frameworks and large development workload.

[0006] According to a first aspect, embodiments of the present invention provide an extension method for a compiler hardware backend, the compiler including a shared deployer, a dynamic loader, and multiple interface adapters, the method including: obtaining preset runtime libraries and preset operator libraries for each processor; compiling based on the preset runtime libraries, preset operator libraries, and interface adapters corresponding to each processor to generate target hardware libraries corresponding to each processor; loading any of the target hardware libraries through the dynamic loader; and determining the task deployment location of the shared deployer based on the type of the target hardware library.

[0007] The compiler hardware backend extension method provided in this invention includes a common deployer, a dynamic loader, and multiple interface adapters within the compiler framework. By compiling the runtime libraries, preset operator libraries, and interface adapters corresponding to each processor, the corresponding target hardware library is obtained. Then, the task deployment location of the common deployer is determined by the type of the target hardware library loaded by the dynamic loader. This reduces the coupling between hardware extension and the compiler. Even if the compiler version changes, only the common deployer and dynamic loader need to be upgraded. Furthermore, the development workload is independent of the number of hardware backends, reducing repetitive work in code development, compilation, and version maintenance, and enabling rapid and readily available compiler support for various processors.

[0008] In conjunction with the first aspect, in the first embodiment of the first aspect, the step of compiling based on the preset runtime library, the preset operator library, and the interface adapter corresponding to each processor to generate the target hardware library corresponding to each processor includes: determining the corresponding target interface adapter from a plurality of interface adapters based on the preset runtime library and the preset operator library; compiling and linking the preset runtime library, the preset operator library, and the target interface adapter to generate the target hardware library.

[0009] The compiler hardware backend extension method provided in this embodiment of the invention allows for different runtime libraries, operator libraries, and interface adapters corresponding to different processors. The runtime library, operator library, and corresponding target interface adapter are compiled into a target hardware library, thereby decoupling the hardware backend compilation from the compiler source code compilation.

[0010] In conjunction with the first aspect, in the second embodiment of the first aspect, loading any of the target hardware libraries through the dynamic loader includes: obtaining the storage location corresponding to each of the target hardware libraries; determining a target storage location from the plurality of storage locations; accessing the target storage location through the dynamic loader; and reading the corresponding target hardware library from the target storage location.

[0011] The compiler hardware backend extension method provided in this embodiment of the invention places different target hardware libraries in different storage locations, which facilitates the dynamic loader to access the target storage location to read and load the corresponding target hardware library, realizing on-demand retrieval of target hardware libraries for any processor.

[0012] In conjunction with the second embodiment of the first aspect, in the third embodiment of the first aspect, determining a target storage location from a plurality of storage locations includes: in response to a selection operation on the plurality of storage locations, determining the target storage location from the plurality of storage locations based on the selection operation.

[0013] The compiler hardware backend extension method provided in this embodiment of the invention supports the selection of storage location, which makes it easier to set the storage location of the target hardware library according to actual needs, making hardware extension more flexible.

[0014] In conjunction with the first aspect, in a fourth embodiment of the first aspect, configuring the shared deployer includes: in response to a first setting operation on the hardware type, setting the interface name of the shared deployer based on the first setting operation; in response to a second setting operation on memory and operators, defining virtual library functions in the header file of the shared deployer based on the second setting operation; wherein the virtual functions include virtual memory library functions and virtual operator library functions.

[0015] The compiler hardware backend extension method provided in this embodiment of the invention enables plug-in extension of the hardware backend by setting a shared deployer interface name and virtual library functions in the compiler, so that the dynamic loader can load the corresponding real library functions accordingly.

[0016] In conjunction with the first aspect, in a fifth embodiment of the first aspect, configuring the dynamic loader includes: in response to a third setting operation for a path call, setting the call information of the dynamic loader based on the third setting operation; and in response to a fourth setting operation for function loading, setting actual function loading information for the dynamic loader based on the fourth setting operation.

[0017] The compiler hardware backend extension method provided in this embodiment of the invention enables rapid compiler support for various processors by setting a dynamic loader in the compiler to load real library functions corresponding to virtual library functions, which facilitates the determination of the task deployment location of the shared deployer based on the real library functions.

[0018] In conjunction with the first aspect, in the sixth embodiment of the first aspect, configuring the interface adapter includes: determining the mapping relationship between the virtual library functions of the shared deployer and the real library functions loaded by the dynamic loader; and generating the interface adapter in the compiler based on the mapping relationship.

[0019] The compiler hardware backend extension method provided in this embodiment of the invention realizes the mapping relationship between virtual library functions and real library functions by setting an interface adapter in the compiler, which facilitates the decoupling of hardware backend extension and compiler framework.

[0020] According to a second aspect, embodiments of the present invention provide an extension device for a compiler hardware backend. The compiler includes a shared deployer, a dynamic loader, and multiple interface adapters. The device includes: an acquisition module for acquiring preset runtime libraries and preset operator libraries for each processor; a compilation module for compiling based on the preset runtime libraries, preset operator libraries, and interface adapters corresponding to each processor to generate target hardware libraries corresponding to each processor; a loading module for loading any of the target hardware libraries through the dynamic loader; and a deployment module for determining the task deployment location of the shared deployer based on the type of the target hardware library.

[0021] According to a third aspect, embodiments of the present invention provide an electronic device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the compiler hardware backend extension method described in the first aspect or any embodiment of the first aspect.

[0022] According to a fourth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to perform an extended method of the compiler hardware backend as described in the first aspect or any embodiment of the first aspect.

[0023] It should be noted that the beneficial effects of the compiler hardware backend extension device, electronic device, and computer-readable storage medium provided in the embodiments of the present invention can be found in the description of the corresponding content in the compiler hardware backend extension method, and will not be repeated here. Attached Figure Description

[0024] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0025] Figure 1 A structural diagram of a conventional compiler is shown in an embodiment of the present invention;

[0026] Figure 2 An extended structure diagram of the compiler hardware backend in an embodiment of the present invention is shown;

[0027] Figure 3 This is a flowchart of an extension method for a compiler hardware backend according to an embodiment of the present invention;

[0028] Figure 4 This is another flowchart of an extended method for the compiler hardware backend according to an embodiment of the present invention;

[0029] Figure 5 This is a structural block diagram of an extension device for a compiler hardware backend according to an embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0032] The continuous diversification of deep learning frameworks and AI processors has led to many-to-many mapping problems, driving the development of AI compilers. Taking the mainstream open-source AI compiler TVM (Tensor Virtual Machine) as an example, its front-end performs model parsing and has achieved integration with common deep learning frameworks, while its back-end handles model deployment. Supported intelligent processors include CPUs and GPUs from various hardware manufacturers. The TVM workflow diagram is shown below. Figure 1 As shown. By analyzing... Figure 1 By developing the source code of the TVM backend and adding a deployment module for a new type of artificial intelligence processor, the TVM hardware backend can be expanded.

[0033] However, for each new AI processor, the hardware deployment portion of the TVM source code needs to be developed, adding the corresponding code for that new AI processor, including hardware type, memory management, operator implementation, and other related aspects. This results in a high degree of coupling between the expansion of the TVM hardware backend and the TVM source code. When the TVM version is updated, the workload of version maintenance also increases with the number of new AI processor types.

[0034] Based on this, the technical solution of the present invention extends the hardware backend of the compiler in a plug-in manner, which solves the problem of high coupling between the current hardware extension and the compiler framework, reduces repetitive work in code development, compilation and version maintenance, and enables the compiler to quickly support new artificial intelligence processors and use them on demand.

[0035] According to an embodiment of the present invention, an embodiment of an extension method for a compiler hardware backend is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0036] This embodiment provides an extension method for a compiler hardware backend for use in an electronic device that deploys a compiler, such as an Artificial Intelligence (AI) compiler like TVM. Figure 2 As shown, the compiler includes a common deployer, a dynamic loader, and multiple interface adapters. The common deployer, dynamic loader, and multiple interface adapters are configured within an AI compiler-based framework, with communication connections between the common deployer and the dynamic loader, and between the dynamic loader and the multiple interface adapters.

[0037] Among them, the shared deployer's memory allocation, data copying and other interfaces are implemented by calling virtual functions, which only need to be defined in the header file; during the runtime phase, the actual implementation of the virtual functions is implemented by the dynamic loader calling the real functions; the interface adapter is used to implement the mapping between virtual functions and actual functions.

[0038] Figure 3 This is a flowchart of an extension method for a compiler hardware backend according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps:

[0039] S11, obtain the preset runtime library and preset operator library for each processor.

[0040] The default runtime library is a pre-configured library of built-in functions for implementing programming languages, based on the runtime parameters of each processor. The default operator library is a pre-configured library of deep learning operators based on the function space mapping of each processor.

[0041] The preset runtime library and preset operator library are configured by technicians as needed for the types of new artificial intelligence processing. Accordingly, the compiler can respond to the technicians' configuration operations and generate the corresponding preset runtime library and preset operator library.

[0042] Taking two processors as an example, if the default runtime library of GPU from vendor A is set to cudart and the default runtime library of MLU from vendor B is set to CNRT, then the compiler's runtime library includes cudart and CNRT. Correspondingly, if the default operator library of GPU from vendor A is set to cuDNN and the default operator library of MLU from vendor B is set to CNNL, then the compiler's operator library includes cuDNN and CNNL.

[0043] S12 compiles based on the preset runtime library, preset operator library and interface adapter corresponding to each processor to generate the target hardware library corresponding to each processor.

[0044] Different processors have different mapping relationships between virtual functions and actual functions, therefore each processor has a corresponding interface adapter. The preset runtime library, preset operator library, and interface adapter are compiled into binary form to obtain a compiled file. This compiled file is then combined with the system components of the electronic device (such as standard libraries and dynamic link libraries) to generate the target hardware library.

[0045] It should be noted that while compiling the target hardware library, the compiler can simultaneously compile the source code of the common deployer and the dynamic loader. That is, the compilation of the common deployer and the dynamic loader is independent of the compilation of the target hardware library, thereby achieving compilation decoupling between the hardware backend and the compiler.

[0046] S13 loads any target hardware library via a dynamic loader.

[0047] After the target hardware libraries for each processor are generated, they are stored in corresponding fixed paths; that is, the storage paths for the target hardware libraries for different processors are different. The dynamic loader can access any storage path and read the target hardware libraries placed in that storage path.

[0048] S14, determine the task deployment location of the shared deployer based on the type of the target hardware library.

[0049] The target hardware library type characterizes the processor's device type, such as MLU, GPU, CPU, etc. The task deployment location determines which processor the compiler needs to deploy the model inference task on. The shared deployer, in conjunction with the processor to which the target hardware library loaded by the dynamic loader belongs, deploys the model inference task to the appropriate processor.

[0050] For example, if the target hardware library for the MLU is placed in the storage path read by the dynamic loader, then the model inference task will be deployed on the MLU processor by the compiler's common deployer; if the target hardware library for the GPU is placed there, then the model inference task will be deployed on the GPU processor.

[0051] The compiler hardware backend extension method provided in this embodiment includes a common deployer, a dynamic loader, and multiple interface adapters within the compiler framework. By compiling the runtime libraries, preset operator libraries, and interface adapters corresponding to each processor, the corresponding target hardware libraries are obtained. Then, the task deployment location of the common deployer is determined by the type of the target hardware library loaded by the dynamic loader. This reduces the coupling between hardware extension and the compiler. Even if the compiler version changes, only the common deployer and dynamic loader need to be upgraded. Furthermore, the development workload is independent of the number of hardware backends, reducing repetitive work in code development, compilation, and version maintenance, and enabling rapid and readily available compiler support for various processors.

[0052] This embodiment provides an extension method for a compiler hardware backend for use in an electronic device that deploys a compiler, such as an Artificial Intelligence (AI) compiler like TVM. Figure 2 As shown, the compiler includes a shared deployer, a dynamic loader, and multiple interface adapters. The shared deployer, dynamic loader, and multiple interface adapters are set up based on the AI ​​compiler framework.

[0053] Specifically, the steps to configure a shared deployer include:

[0054] (1) In response to a first setting operation on the hardware type, set the interface name of the shared deployer based on the first setting operation.

[0055] The first setup operation is for technicians to add a shared deployer in the compiler backend via program code.

[0056] Specifically, technicians can add a shared deployer device interface to the hardware type section based on the compiler framework, and set the interface name of this device interface. This device interface is just a layer of encapsulation and does not point to a specific processor. Correspondingly, the compiler can respond to the technician's first setting operation and generate the corresponding shared deployer and interface name in the compiler backend based on this first setting operation.

[0057] For example, add a common deployer with the interface name "GeneralDevice" to the hardware type section. This common deployer can point to either the MLU or the GPU. Which processor backend it points to is determined by the dynamic loader.

[0058] (2) In response to the second setup operation on memory and operators, define virtual library functions in the header file of the common deployer based on the second setup operation.

[0059] Virtual functions include virtual memory library functions and virtual operator library functions.

[0060] The second setup operation involves technicians configuring virtual memory library functions and virtual operator library functions through program code.

[0061] Specifically, in the memory management section, technicians can define corresponding virtual memory library functions in the header file according to the compiler's framework. These virtual memory library functions include memory allocation functions, data copy functions, etc. In the operator implementation section, technicians can define corresponding virtual operator library functions in the header file according to the compiler's framework. These virtual operator library functions include convolution operator functions, matrix multiplication operator functions, etc. Correspondingly, the compiler deployed in the electronic device can respond to the technician's second setting operation and generate definitions for the virtual memory library functions and virtual operator library functions in the header file according to this second setting operation.

[0062] It should be noted that the shared deployer's interfaces for memory allocation, data copying, etc., are implemented by calling virtual functions defined in header files, such as the memory allocation function `generalMalloc` and the data copy function `generalMemcpy`. The actual implementation of these virtual functions is set by the dynamic loader. Similarly, surface-level operator functions such as the convolution operator function `generalConv` and the matrix multiplication operator function `generalMatmul` are compiled and implemented at runtime by the dynamic loader calling the actual operator functions.

[0063] Specifically, the steps for configuring a dynamic loader include:

[0064] (1) In response to a third setting operation on a path call, set the dynamic loader call information based on the third setting operation.

[0065] The third setup operation involves technicians adding a path call operation for the dynamic loader in the compiler backend through program code.

[0066] Specifically, technicians can add a dynamic loader to the hardware type section based on the compiler framework and set the path call function for the dynamic loader to access the target hardware library under a specified storage path. For example, the Linux dynamic library explicit call function dlopen can be used to implement path calling for the target hardware library.

[0067] (2) In response to the fourth setting operation on function loading, set the function loading information of the dynamic loader based on the fourth setting operation.

[0068] The fourth setup operation involves technicians adding a function loading operation for a dynamic loader in the compiler backend via program code.

[0069] Specifically, technicians can add a dynamic loader to the hardware type section based on the compiler framework and set the loading function of the dynamic loader. This loading function retrieves the actual library functions corresponding to the virtual library functions from the target hardware library. The actual library functions include actual memory library functions and actual operator library functions. For example, the Linux dynamic library can explicitly call the function `dlsym` to retrieve the actual library functions from the target hardware library.

[0070] Specifically, the steps for configuring the interface adapter include:

[0071] (1) Determine the mapping relationship between the virtual library functions of the shared deployer and the real library functions loaded by the dynamic loader.

[0072] The virtual library functions of the shared deployer (such as generalMalloc, generalMemcpy, and generalConv) are based on the compiler framework. Their inputs, outputs, and parameter usage must meet the compiler framework requirements. However, the runtime libraries and operator libraries of different processors have differences in their definitions, such as parameter order (for example, the runtime library CNRT and the operator library CNNL for the MLU; the runtime library cudart and the operator library cuDNN for the GPU, whose memory allocation, data copying, and convolution calculation function definitions are different). In this case, the mapping relationship according to their respective specifications is determined based on the virtual library functions of the shared deployer and the real library functions loaded by the dynamic loader.

[0073] (2) Generate interface adapters in the compiler based on mapping relationships.

[0074] Technicians can write corresponding program code based on this mapping relationship to achieve the adaptation between virtual library functions and real library functions. Correspondingly, the compiler can respond to the technicians' development operations and generate an interface adapter based on these operations, enabling the dynamic loader to obtain the actual library functions of the runtime library and operator library for each processor through this interface adapter.

[0075] This embodiment enables plug-in-style expansion of the hardware backend by setting the interface name and virtual library functions of the shared deployer in the compiler. This allows the dynamic loader to load the corresponding real library functions, facilitating the determination of the shared deployer's task deployment location based on the real library functions, thus achieving rapid compiler support for various processors. Furthermore, by setting an interface adapter in the compiler to implement the mapping relationship between virtual and real library functions, the decoupling of hardware backend expansion from the compiler framework is facilitated.

[0076] Figure 4 This is a flowchart of an extension method for a compiler hardware backend according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps:

[0077] S21, Obtain the preset runtime library and preset operator library for each processor. For detailed explanations, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0078] S22 compiles based on the preset runtime library, preset operator library and interface adapter corresponding to each processor to generate the target hardware library corresponding to each processor.

[0079] Specifically, step S22 above may include:

[0080] S221, determine the corresponding target interface adapter from multiple interface adapters based on the preset runtime library and preset operator library.

[0081] Different processors have different preset runtime libraries and preset operator libraries, and different processors also have different interface adapters. When the preset runtime library and preset operator library are obtained, the actual library functions of the processor they represent can be determined based on the preset runtime library and preset operator library. That is, the processor type can be determined according to the preset runtime library and preset operator library, and thus the target interface adapter corresponding to the processor type can be determined from multiple interface adapters based on the processor type.

[0082] S222 compiles and links the preset runtime library, preset operator library, and target interface adapter to generate the target hardware library.

[0083] Since the default runtime library, default operator library, and target interface adapter are all implemented based on program code, they need to be compiled into binary form of computer language, i.e., a compiled file is generated. Then, this compiled file is combined and linked with the components of the electronic device (such as standard libraries, dynamic link libraries, etc.) to generate an executable file, which constitutes the target hardware library.

[0084] S23 loads any target hardware library via a dynamic loader.

[0085] Specifically, step S23 above may include:

[0086] S231, obtain the storage location corresponding to each target hardware library.

[0087] Storage location is used to characterize the path where each target hardware library is stored. After generating target hardware libraries for each processor, the storage location of each target hardware library can be determined through pre-set storage rules.

[0088] S232, determine the target storage location from multiple storage locations.

[0089] The target storage location is the location where the target hardware library is called. To determine the target storage location, the corresponding target hardware library can be determined based on the type of processor to be added. Then, by querying multiple storage locations, the target storage location corresponding to the required target hardware library can be determined.

[0090] Optionally, step S232 may include: in response to a selection operation on multiple storage locations, determining a target storage location from the multiple storage locations based on the selection operation.

[0091] The selection operation refers to the action of a technician choosing a target storage location through a visual interface, or editing the selection program through a development interface. Correspondingly, the dynamic loader in the compiler can respond to this selection operation and choose the target storage location from multiple storage locations.

[0092] S233 accesses the target storage location through the dynamic loader and reads the corresponding target hardware library from the target storage location.

[0093] The dynamic loader accesses the determined target storage location and reads and loads the target hardware library placed there. Therefore, by changing the target storage location that the dynamic loader reads or changing the target hardware library stored there, plug-in extensions for the compiler backend can be achieved.

[0094] S24, determine the task deployment location of the shared deployer based on the type of the target hardware library. For detailed explanation, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0095] The compiler hardware backend extension method provided in this embodiment uses different runtime libraries, operator libraries, and interface adapters for different processors. The runtime libraries, operator libraries, and corresponding target interface adapters are compiled into target hardware libraries, thereby decoupling hardware backend compilation from compiler source code compilation. Different target hardware libraries are placed in different storage locations, allowing the dynamic loader to access and load the corresponding target hardware libraries from these locations, achieving on-demand retrieval of target hardware libraries for any processor. The support for selecting storage locations allows for setting the storage location of target hardware libraries according to actual needs, making hardware expansion more flexible.

[0096] This embodiment also provides an extension device for the compiler hardware backend, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.

[0097] This embodiment provides an extension device for the compiler hardware backend, such as... Figure 5 As shown, the device includes:

[0098] The acquisition module 31 is used to acquire the preset runtime library and preset operator library for each processor.

[0099] The compilation module 32 is used to compile based on the preset runtime library, preset operator library and interface adapter corresponding to each processor, and generate the target hardware library corresponding to each processor.

[0100] Loading module 33 is used to load any target hardware library via a dynamic loader.

[0101] Deployment module 34 is used to determine the task deployment location of the shared deployer based on the type of the target hardware library.

[0102] Optionally, the expansion device for the compiler hardware backend may further include:

[0103] The shared deployer configuration module is used to respond to a first configuration operation on the hardware type, and to configure the interface name of the shared deployer based on the first configuration operation; and to respond to a second configuration operation on the memory and operators, to define virtual library functions in the header file of the shared deployer based on the second configuration operation.

[0104] The dynamic loader setting module is used to respond to the third setting operation for path invocation, and set the dynamic loader invocation information based on the third setting operation; and to respond to the fourth setting operation for function loading, and set the dynamic loader function loading information based on the fourth setting operation.

[0105] The interface adapter setting module is used to determine the mapping relationship between the virtual library functions of the shared deployer and the real library functions loaded by the dynamic loader; based on the mapping relationship, the interface adapter is generated in the compiler.

[0106] Optionally, the above-mentioned compilation module 32 may include:

[0107] The target determination submodule is used to determine the corresponding target interface adapter from multiple interface adapters based on the preset runtime library and preset operator library.

[0108] The compilation submodule is used to compile and link the preset runtime library, preset operator library, and target interface adapter to generate the target hardware library.

[0109] Optionally, loading module 33 may include:

[0110] The storage location acquisition submodule is used to obtain the storage location corresponding to each target hardware library.

[0111] The storage location determination submodule is used to determine the target storage location from multiple storage locations.

[0112] The read submodule is used to access the target storage location through the dynamic loader and read the corresponding target hardware library from the target storage location.

[0113] Optionally, the aforementioned storage location determination submodule is further configured to: in response to a selection operation on multiple storage locations, determine a target storage location from the multiple storage locations based on the selection operation.

[0114] In this embodiment, the compiler hardware backend expansion device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0115] The further functional descriptions of each module and submodule are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0116] The compiler hardware backend extension device provided in this embodiment compiles the runtime libraries, preset operator libraries, and interface adapters corresponding to each processor to obtain the corresponding target hardware libraries. Then, the task deployment location of the common deployer is determined by the type of the target hardware library loaded by the dynamic loader. This reduces the coupling between hardware extension and the compiler. Even if the compiler version changes, only the common deployer and dynamic loader need to be upgraded. Furthermore, the development workload is independent of the number of hardware backends, reducing repetitive work in code development, compilation, and version maintenance. This enables rapid compiler support for various processors and on-demand availability.

[0117] This invention also provides an electronic device having the above-described features. Figure 5 The compiler hardware backend expansion device shown.

[0118] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an optional embodiment of the present invention, such as... Figure 6 As shown, the terminal may include: at least one processor 401, such as a CPU (Central Processing Unit), at least one communication interface 403, a memory 404, and at least one communication bus 402. The communication bus 402 is used to enable communication between these components. The communication interface 403 may include a display screen and a keyboard; optionally, the communication interface 403 may also include a standard wired interface or a wireless interface. The memory 404 may be high-speed RAM (Random Access Memory) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 404 may also be at least one storage device located remotely from the aforementioned processor 401. The processor 401 may be combined with... Figure 5 The described apparatus has an application program stored in memory 404, and a processor 401 calls the program code stored in memory 404 to perform any of the above method steps.

[0119] The communication bus 402 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 402 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0120] The memory 404 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 404 may also include a combination of the above types of memory.

[0121] The processor 401 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.

[0122] The processor 401 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0123] Optionally, memory 404 is also used to store program instructions. Processor 401 can invoke program instructions to implement the compiler hardware backend extension method as shown in the above embodiments of this application.

[0124] This invention also provides a non-transitory computer storage medium storing computer-executable instructions that can execute the extended methods of the compiler hardware backend in any of the above method embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0125] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for extending the hardware backend of a compiler, characterized in that, The compiler includes a shared deployer, a dynamic loader, and multiple interface adapters; the method includes: Obtain the preset runtime library and preset operator library for each processor; Compile based on the preset runtime library, preset operator library and interface adapter corresponding to each processor to generate the target hardware library corresponding to each processor; Load any of the target hardware libraries using the dynamic loader; The task deployment location of the shared deployer is determined based on the type of the target hardware library; The shared deployer's memory allocation and data copying interfaces are implemented by calling virtual functions, which only need to be defined in the header file. During runtime, the virtual functions are implemented by the dynamic loader calling real functions. The interface adapter is used to implement the mapping between virtual functions and real functions.

2. The method according to claim 1, characterized in that, The process of compiling based on the preset runtime library, preset operator library, and interface adapter corresponding to each processor to generate the target hardware library corresponding to each processor includes: Based on the preset runtime library and preset operator library, the corresponding target interface adapter is determined from the multiple interface adapters; The preset runtime library, the preset operator library, and the target interface adapter are compiled and linked to generate the target hardware library.

3. The method according to claim 1, characterized in that, The loading of any of the target hardware libraries via the dynamic loader includes: Obtain the storage location corresponding to each of the target hardware libraries; The target storage location is determined from the plurality of said storage locations; The target storage location is accessed through the dynamic loader, and the corresponding target hardware library is read from the target storage location.

4. The method according to claim 3, characterized in that, Determining the target storage location from the plurality of said storage locations includes: In response to a selection operation of a plurality of said storage locations, the target storage location is determined from the plurality of said storage locations based on the selection operation.

5. The method according to claim 1, characterized in that, Configuring the shared deployer includes: In response to a first setting operation on the hardware type, the interface name of the shared deployer is set based on the first setting operation; In response to a second setting operation on memory and operators, virtual library functions are defined in the header file of the common deployer based on the second setting operation; The virtual library functions include virtual memory library functions and virtual operator library functions.

6. The method according to claim 1, characterized in that, Configuring the dynamic loader includes: In response to a third setting operation for a path call, the call information of the dynamic loader is set based on the third setting operation; In response to a fourth setting operation on function loading, the function loading information of the dynamic loader is set based on the fourth setting operation.

7. The method according to claim 1, characterized in that, Configuring the interface adapter includes: Determine the mapping relationship between the virtual library functions of the shared deployer and the actual library functions loaded by the dynamic loader; The interface adapter is generated in the compiler based on the mapping relationship.

8. An expansion device for a compiler hardware backend, characterized in that, The compiler includes a shared deployer, a dynamic loader, and multiple interface adapters; the apparatus includes: The acquisition module is used to acquire the preset runtime library and preset operator library for each processor; The compilation module is used to compile based on the preset runtime library, the preset operator library and the interface adapter corresponding to each processor, and generate the target hardware library corresponding to each processor. A loading module is used to load any of the target hardware libraries via the dynamic loader; The deployment module is used to determine the task deployment location of the shared deployer based on the type of the target hardware library; The shared deployer's memory allocation and data copying interfaces are implemented by calling virtual functions, which only need to be defined in the header file. During runtime, the virtual functions are implemented by the dynamic loader calling real functions. The interface adapter is used to implement the mapping between virtual functions and real functions.

9. An electronic device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the extended method of the compiler hardware backend as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the extended method of the compiler hardware backend as described in any one of claims 1-7.

Images