Accelerator card operator adaptation method, device, computer equipment, storage medium

Abstract

This application relates to an accelerator card operator adaptation method and apparatus, which involves: placing the operator source code in a predetermined folder; converting the operator source code into an Abstract Syntax Tree (AST); generating a Looplet dialect based on the AST using the MLIR tool; optimizing the accelerator card operator within the Looplet dialect according to the accelerator card architecture; converting the Looplet dialect into an affine dialect using the MLIR tool; optimizing the accelerator card operator using a polyhedral model based on the affine dialect; converting the affine dialect into an LLVM dialect using the MLIR tool; converting the LLVM dialect into an LLVM IR using the LLVM tool; and compiling the LLVM IR into an executable binary file using the LLC tool under LLVM. This solves the technical problem of existing technologies requiring different operators to be built for domestically produced accelerator cards with different architectures, resulting in high cost and low efficiency. It achieves the technical effect of deploying the same set of optimized operator source code on domestically produced accelerator cards with different architectures, resulting in high adaptability, low cost, and high efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an accelerator card operator adaptation method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] Domestically produced accelerator cards are commonly used to accelerate the training and inference of deep learning, while operator porting is the process of mapping the default operators of deep learning frameworks onto accelerator cards. In response to the development of the domestic accelerator card industry, an increasing number of domestically produced accelerator cards require operator optimization.

[0003] However, for existing operator optimization and adaptation methods, different operators need to be built for domestic accelerator cards with different architectures, which undoubtedly increases the design cost. Summary of the Invention

[0004] Therefore, it is necessary to provide a multi-accelerator card operator adaptation method, apparatus, computer equipment, storage medium, and computer program product to address the above-mentioned technical problems.

[0005] Firstly, this application provides an accelerator card operator adaptation method, the method comprising:

[0006] Place the operator source code into the designated folder;

[0007] The source code of the operator is transformed into an abstract syntax tree (AST).

[0008] Based on the abstract syntax tree (AST), a looplet dialect is generated using the MLIR tool.

[0009] Based on the architecture of the accelerator card, the accelerator card operators are optimized within the Looplet dialect;

[0010] The Looplet dialect is converted to an affine dialect using the MLIR tool;

[0011] Based on the aforementioned affine dialect, the accelerator card operator is optimized using a polyhedral model;

[0012] The affine dialect was converted into an llvm dialect using the MLIR tool.

[0013] Convert LLVM dialect to LLVM IR using LLVM tools;

[0014] Use the LLC tool under LLVM to compile LLVM IR into an executable binary file.

[0015] In one embodiment, the Looplet dialect comes from the core language Looplet in the finch compiler.

[0016] In one embodiment, optimizing the accelerator card operator using a polyhedral model based on the affine dialect includes:

[0017] Parse and construct the affine dialect;

[0018] The AffineAnalysis tool was used to analyze the dependencies between different loop iterations and array accesses.

[0019] Construct a graph structure to represent the dependencies;

[0020] The iteration space of the affine.for loop in the process of parsing and constructing the affine dialect is represented as a region in a polyhedral model;

[0021] Based on data dependency analysis, the dependency relationship is used as a constraint condition in the polyhedral model;

[0022] Scheduling optimization uses a polyhedral model to reschedule the execution order of loops;

[0023] Identify independent loop iterations and achieve parallel execution by generating affine.parallel;

[0024] Generate a new Affine Dialect IR.

[0025] In one embodiment, the scheduling optimization uses a polyhedral model to reschedule the execution order of loops, including: loop rearrangement, loop tiling, and loop merging.

[0026] In one embodiment, parsing and constructing the affine dialect includes: affine.for operation, affine.if operation, affine.load operation, and affine.store operation.

[0027] In one embodiment, generating a new Affine Dialect IR includes remapping the iteration space and scheduling information, and expressing them as affine.for and affine.if operations in Affine Dialect.

[0028] Secondly, this application also provides an accelerator card operator adaptation device, the device comprising:

[0029] The input module is used to place the operator source code into a designated folder;

[0030] The conversion module is used to convert the operator source code into an abstract syntax tree (AST).

[0031] The processing module is used to generate a Looplet dialect based on the Abstract Syntax Tree (AST) using the MLIR tool;

[0032] The first optimization module is used to optimize the accelerator card operators within the Looplet dialect according to the architecture of the accelerator card.

[0033] The first conversion module is used to convert the Looplet dialect into an affinedialect using the MLIR tool;

[0034] The second optimization module is used to optimize the accelerator card operator based on the affine dialect using a polyhedral model;

[0035] The second conversion module is used to convert the affine dialect into the llvm dialect using the MLIR tool;

[0036] The third conversion module is used to convert LLVM dialect to LLVM IR using LLVM tools;

[0037] The compilation module is used to compile LLVM IR into executable binaries using the LLC tool under LLVM.

[0038] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0039] Place the operator source code into the designated folder;

[0040] The source code of the operator is transformed into an abstract syntax tree (AST).

[0041] Based on the abstract syntax tree (AST), a looplet dialect is generated using the MLIR tool.

[0042] Based on the architecture of the accelerator card, the accelerator card operators are optimized within the Looplet dialect;

[0043] The Looplet dialect is converted to an affine dialect using the MLIR tool;

[0044] Based on the aforementioned affine dialect, the accelerator card operator is optimized using a polyhedral model;

[0045] The affine dialect was converted into an llvm dialect using the MLIR tool.

[0046] Convert LLVM dialect to LLVM IR using LLVM tools;

[0047] Use the LLC tool under LLVM to compile LLVM IR into an executable binary file.

[0048] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps: placing operator source code into a predetermined folder;

[0049] The source code of the operator is transformed into an abstract syntax tree (AST).

[0050] Based on the abstract syntax tree (AST), a looplet dialect is generated using the MLIR tool.

[0051] Based on the architecture of the accelerator card, the accelerator card operators are optimized within the Looplet dialect;

[0052] The Looplet dialect is converted to an affine dialect using the MLIR tool;

[0053] Based on the aforementioned affine dialect, the accelerator card operator is optimized using a polyhedral model;

[0054] The affine dialect was converted into an llvm dialect using the MLIR tool.

[0055] Convert LLVM dialect to LLVM IR using LLVM tools;

[0056] Use the LLC tool under LLVM to compile LLVM IR into an executable binary file.

[0057] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0058] Place the operator source code into the designated folder;

[0059] The source code of the operator is transformed into an abstract syntax tree (AST).

[0060] Based on the abstract syntax tree (AST), a looplet dialect is generated using the MLIR tool.

[0061] Based on the architecture of the accelerator card, the accelerator card operators are optimized within the Looplet dialect;

[0062] The Looplet dialect is converted to an affine dialect using the MLIR tool;

[0063] Based on the aforementioned affine dialect, the accelerator card operator is optimized using a polyhedral model;

[0064] The affine dialect was converted into an llvm dialect using the MLIR tool.

[0065] Convert LLVM dialect to LLVM IR using LLVM tools;

[0066] Use the LLC tool under LLVM to compile LLVM IR into an executable binary file.

[0067] The aforementioned accelerator card operator adaptation method, apparatus, computer equipment, storage medium, and computer program product, through the following steps: placing the operator source code in a predetermined folder; converting the operator source code into an Abstract Syntax Tree (AST); generating a Looplet dialect based on the AST using the MLIR tool; optimizing the accelerator card operator within the Looplet dialect according to the accelerator card architecture; converting the Looplet dialect into an affine dialect using the MLIR tool; optimizing the accelerator card operator using a polyhedral model based on the affine dialect; converting the affine dialect into an LLVM dialect using the MLIR tool; converting the LLVM dialect into an LLVM IR using the LLVM tool; and compiling the LLVM IR into an executable binary file using the LLC tool under LLVM. This solves the technical problem of existing technologies requiring the construction of different operators for domestically produced accelerator cards with different architectures, resulting in high cost and low efficiency. It achieves the technical effect of deploying the same set of optimized operator source code on domestically produced accelerator cards with different architectures, resulting in high adaptability, low cost, and high efficiency. Attached Figure Description

[0068] Figure 1 This is a flowchart illustrating an accelerator card operator adaptation method in one embodiment;

[0069] Figure 2 This is a flowchart illustrating the accelerator card operator adaptation method in another embodiment;

[0070] Figure 3 This is a structural block diagram of an accelerator card operator adapter device in one embodiment;

[0071] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0073] The following technologies were mainly used in this application:

[0074] 1. MLIR (Multi-Level Intermediate Representation)

[0075] MLIR is a modular intermediate representation framework that supports the definition and transformation of intermediate representations across various compilers. It allows for optimization at different levels of abstraction, making it particularly suitable for modern compilers and hardware accelerators. MLIR supports a variety of operators and types through the Dialect system, providing support for multiple programming languages ​​and computational models.

[0076] 2.LLVM (Low-Level Virtual Machine)

[0077] LLVM is a framework for compiler building that provides a flexible intermediate representation (IR) and toolchain for compiling and optimizing programs. LLVM is primarily used to generate efficient machine code, supports multiple front-ends (such as Clang) and back-ends (such as x86, ARM, and other hardware architectures), and can perform various advanced optimizations.

[0078] 3. Clang

[0079] Clang is a C, C++, and Objective-C compiler frontend based on LLVM. It parses source code into an Abstract Syntax Tree (AST) and then transforms it into an LLVM IR for further optimization and code generation by LLVM. Clang is known for its fast compilation speed, modular design, and high-quality error messages.

[0080] 4. Dialect

[0081] Dialect is a core concept in MLIR, representing a set of operators and types for a specific domain (such as tensor operations or control flow). Different Dialects can coexist and be converted between each other in MLIR. For example, there can be a TensorFlowDialect for representing tensor computations and an Affine Dialect for representing loop and array access patterns.

[0082] 5. AST (Abstract Syntax Tree)

[0083] An Abstract Syntax Tree (AST) is a tree-like representation of source code that describes its syntactic structure. The compiler uses the AST to understand and analyze the program structure, then transforms it into an intermediate representation (such as LLVM IR or MLIR). The AST is a core data structure in the compiler front-end, used for syntax checking, type checking, and other compiler analysis.

[0084] 6. Affine (Affine Dialect)

[0085] Affine is a dialect in MLIR that focuses on representing and optimizing loop and array access patterns. AffineDialect provides a set of operators for expressing linear access patterns, which can help the compiler identify and optimize loop transformations such as loop unrolling, loop swapping, and parallelization.

[0086] 7. Polyhedral Model and its Optimization

[0087] The polyhedral model is a mathematical model used to represent and optimize the space of nested loops and array accesses. By using linear inequalities, the polyhedral model can precisely capture the iteration space of loops and is used for complex loop transformations and parallelization optimizations. This model is widely used in compilers to improve the performance of computationally intensive programs.

[0088] In one embodiment of this application, such as Figure 1 As shown, an accelerator card operator adaptation method is provided, the method comprising:

[0089] S100, place the operator source code into the designated folder.

[0090] In this application, the C / C++ source code of the operator is placed in the specified folder.

[0091] S200, the operator source code is transformed into an abstract syntax tree (AST).

[0092] In this application, the clang compiler transforms the operator source code into an abstract syntax tree (AST).

[0093] S300, Based on the abstract syntax tree (AST), generate a Looplet dialect using the MLIR tool.

[0094] S400, based on the architecture of the accelerator card, optimizes the accelerator card operators within the Looplet dialect.

[0095] Based on the different architectures of domestic accelerator cards and the different storage formats of sparse data, the operators are adapted and optimized within the Looplet dialect.

[0096] In this embodiment, the Looplet dialect used by S300 and S400 comes from the core language Looplet in the finch compiler. It is mainly optimized for different sparse formats and can also process the data to be processed and complete operator adaptation for different architectures of different domestic accelerator cards. Its main formats are as follows:

[0097] Lookup(body(idx)) is an arbitrary scalar sequence, where the element at index idx can be calculated from body(idx). The entire Lookup Looplet is similar to an array.

[0098] Run(body) is used to describe a sequence consisting of repeated identical scalar values ​​(x). That is, a large number of repeating elements only require one storage unit.

[0099] Spike(body, tail) describes a sequence consisting of repeated identical scalar values ​​(body), followed by a different scalar value (tail). In other words, a Run Looplet is followed by a different value. It's worth noting that the run part can be empty, meaning the entire spike Looplet contains only one value.

[0100] A Pipeline(Phase(stride,body(ext)),...) is a concatenation of several different sub-loops in a sequence. Each phase declares its corresponding range (ending with stride) and a sub-body(ext) of a target sub-range. A looplet can be viewed as a struct, and a pipeline is an array of looplets.

[0101] Stepper(seek(idx), stride, body(ext), next) repeatedly applies the same sub-looplet body(ext), with each clause ending with stride. Stepper is evaluated iteratively, so next advances the state to the next looplet, and seek(idx) initializes the variable for the starting index idx. It can be viewed as a pipeline looplet where each sub-looplet is identical and has a stride of 1.

[0102] The `Jumper(seek(idx), stride, body(ext), next)` function is similar to `stepper`, but `ext` can be wider than `stride`, spanning multiple child loops, thus accelerating iteration (e.g., galloping). It can be viewed as a pipeline looplet where each child looplet is identical but has a different stride.

[0103] Shift(delta, body) is a wrapper that moves all declarations of body by delta (similar to an offset). Shift is necessary because extent is absolute, not relative.

[0104] Switch(Case(cond,body),...) represents the first child looplet body that evaluates to true at runtime, equivalent to ifelse.

[0105] S500 uses the MLIR tool to convert the Looplet dialect into an affine dialect.

[0106] Using the MLIR tool to convert the affine dialect into the LLVM dialect is a necessary process for generating LLVM IR from the MLIR dialect.

[0107] S600, based on the affine dialect, optimizes the accelerator card operator using a polyhedral model.

[0108] S700 uses the MLIR tool to convert the affine dialect into the llvm dialect.

[0109] The S800 uses LLVM tools to convert LLVM dialects to LLVM IRs.

[0110] S900 uses the LLC tool under LLVM to compile LLVM IR into an executable binary file.

[0111] The aforementioned accelerator card operator adaptation method, apparatus, computer equipment, storage medium, and computer program product, through the following steps: placing the operator source code in a predetermined folder; converting the operator source code into an Abstract Syntax Tree (AST); generating a Looplet dialect based on the AST using the MLIR tool; optimizing the accelerator card operator within the Looplet dialect according to the accelerator card architecture; converting the Looplet dialect into an affine dialect using the MLIR tool; optimizing the accelerator card operator using a polyhedral model based on the affine dialect; converting the affine dialect into an LLVM dialect using the MLIR tool; converting the LLVM dialect into an LLVM IR using the LLVM tool; and compiling the LLVM IR into an executable binary file using the LLC tool under LLVM. This solves the technical problem of existing technologies requiring the construction of different operators for domestically produced accelerator cards with different architectures, resulting in high cost and low efficiency. It achieves the technical effect of deploying the same set of optimized operator source code on domestically produced accelerator cards with different architectures, resulting in high adaptability, low cost, and high efficiency.

[0112] In one embodiment, please refer to Figure 2 The S600 includes:

[0113] S610, parse and construct the affine dialect.

[0114] Affine Dialect is a key part of MLIR used to represent linear loops and array access patterns, typically including operations such as affine.for, affine.if, affine.load, and affine.store. These operations are constructed into a mlir::ModuleOp, which is the main data structure that will be operated on throughout the optimization process.

[0115] The S620 uses the AffineAnalysis tool to analyze the dependencies between different loop iterations and array accesses.

[0116] Tools such as AffineAnalysis are used to analyze the dependencies between different loop iterations and array accesses. These dependencies define the program's correctness constraints, ensuring that any optimizations do not break these dependencies.

[0117] S630, Construct a graph structure to represent the dependencies.

[0118] Construct a graph structure to represent these dependencies, which will guide how to rearrange loops and adjust access patterns during the optimization process.

[0119] S640 represents the iteration space of the affine.for loop in the process of parsing and constructing the affine dialect as a region in a polyhedral model.

[0120] The iteration space of each affine.for loop can be represented as a region (polyhedron) in a polyhedral model, typically defined by linear inequalities. This model describes all possible combinations of iterations.

[0121] S650, based on data dependency analysis, uses dependencies as constraints in the polyhedral model.

[0122] Based on data dependency analysis, dependencies are treated as constraints in the polyhedral model. These constraints affect the way loop scheduling and transformations are performed.

[0123] S660, scheduling optimization, uses a polyhedral model to reschedule the execution order of loops.

[0124] Using a polyhedral model to reorder the execution of loops minimizes dependency conflicts and optimizes data locality. This can include:

[0125] Loop Interchange: Changes the order of nested loops to optimize memory access patterns.

[0126] Loop Tiling: Divide large loops into smaller blocks to improve cache hit rate.

[0127] Loop fusion: merges independent loops to reduce loop overhead and improve parallelism.

[0128] S670 identifies independent loop iterations and enables parallel execution by generating affine.parallel.

[0129] Identify independent loop iterations and achieve parallel execution by generating affine.parallel or other parallel constructs.

[0130] S680 generates a new Affine Dialect IR.

[0131] After application optimization, a new Affine Dialect IR is generated. This process involves remapping the iteration space and scheduling information, expressing them as operations such as affine.for and affine.if in Affine Dialect.

[0132] In summary, compared with the prior art, the above-described technical solutions conceived by this invention can achieve the following beneficial effects:

[0133] (1) Due to the introduction of the MLIR-llvm compilation route, and MLIR's ability to generate code for various hardware platforms, including CPUs, GPUs, and TPUs, its scalability allows it to quickly adapt to new hardware architectures. Therefore, domestically produced accelerator cards designed for different architectures can achieve compatibility with different operators.

[0134] (2) MLIR allows developers to define their own Dialects, thereby supporting the needs of specific domains. This invention introduces the Looplet language designed for sparse storage formats and designs it as a new dialect, which can effectively adapt and optimize sparse operators for different domestic accelerator card architectures.

[0135] (3) Combining the MLIR compilation route with the polyhedral model and optimizing the operators during the compilation process greatly helps in the fusion of multiple operators and the optimization of multi-layer loops. Existing polyhedral technology can be introduced into the AI ​​compiler for specific function optimization.

[0136] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0137] Based on the same inventive concept, this application also provides an accelerator card operator adaptation device for implementing the above-mentioned method. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of the one or more accelerator card operator adaptation device embodiments provided below can be found in the limitations of the accelerator card operator adaptation method described above, and will not be repeated here.

[0138] In one embodiment, such as Figure 3 As shown, an accelerator card operator adapter is provided, comprising:

[0139] Input module 100 is used to place the operator source code into a predetermined folder.

[0140] The conversion module 200 is used to convert the operator source code into an abstract syntax tree (AST).

[0141] Processing module 300 is used to generate Loopletdialect using the MLIR tool based on the Abstract Syntax Tree (AST).

[0142] The first optimization module 400 is used to optimize the accelerator card operators within the Looplet dialect according to the architecture of the accelerator card.

[0143] The first conversion module 500 is used to convert the Looplet dialect into an affinedialect using an MLIR tool.

[0144] The second optimization module 600 is used to optimize the accelerator card operator based on the affine dialect using a polyhedral model.

[0145] The second conversion module 700 is used to convert the affine dialect into llvmdialect using the MLIR tool.

[0146] The third conversion module 800 is used to convert LLVM dialect to LLVM IR using LLVM tools.

[0147] Compiler module 900 is used to compile LLVM IR into executable binary files using the LLC tool under LLVM.

[0148] In one embodiment, the Looplet dialect comes from the core language Looplet in the finch compiler.

[0149] In one embodiment, the second optimization module 600 is further configured to:

[0150] Parse and construct the affine dialect;

[0151] The AffineAnalysis tool was used to analyze the dependencies between different loop iterations and array accesses.

[0152] Construct a graph structure to represent the dependencies;

[0153] The iteration space of the affine.for loop in the process of parsing and constructing the affine dialect is represented as a region in a polyhedral model;

[0154] Based on data dependency analysis, the dependency relationship is used as a constraint condition in the polyhedral model;

[0155] Scheduling optimization uses a polyhedral model to reschedule the execution order of loops;

[0156] Identify independent loop iterations and achieve parallel execution by generating affine.parallel;

[0157] Generate a new Affine Dialect IR.

[0158] In one embodiment, the scheduling optimization uses a polyhedral model to reschedule the execution order of loops, including: loop rearrangement, loop tiling, and loop merging.

[0159] In one embodiment, the second optimization module 600 is further configured to perform: affine.for operation, affine.if operation, affine.load operation, and affine.store operation.

[0160] In one embodiment, the second optimization module 600 is further configured to: remap the iteration space and scheduling information, and express them as affine.for and affine.if operations in Affine Dialect.

[0161] Each module in the aforementioned accelerator card operator adapter can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0162] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores preset data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements an accelerator card operator adaptation method.

[0163] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0164] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described accelerator card operator adaptation method.

[0165] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the above-described accelerator card operator adaptation method.

[0166] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described accelerator card operator adaptation method.

[0167] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0168] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0169] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for adapting accelerator card operators, characterized in that, The method includes: Place the operator source code into the designated folder; The source code of the operator is transformed into an abstract syntax tree (AST). Based on the abstract syntax tree (AST), a looplet dialect is generated using the MLIR tool. Based on the architecture of the accelerator card, the accelerator card operators are optimized within the Looplet dialect; The Looplet dialect is converted to an affine dialect using the MLIR tool; Based on the aforementioned affine dialect, the accelerator card operator is optimized using a polyhedral model; The affine dialect was converted into an llvm dialect using the MLIR tool. Convert LLVM dialect to LLVM IR using LLVM tools; Use the LLC tool under LLVM to compile LLVM IR into an executable binary file; The optimization of the accelerator card operator based on the affine dialect using a polyhedral model includes: Parse and construct the affine dialect; The AffineAnalysis tool was used to analyze the dependencies between different loop iterations and array accesses. Construct a graph structure to represent the dependencies; The iteration space of the affine.for loop in the process of parsing and constructing the affine dialect is represented as a region in a polyhedral model; Based on data dependency analysis, the dependency relationship is used as a constraint condition in the polyhedral model; Scheduling optimization uses a polyhedral model to reschedule the execution order of loops; Identify independent loop iterations and achieve parallel execution by generating affine.parallel; Generate a new Affine Dialect IR; The generation of a new Affine Dialect IR includes: remapping the iteration space and scheduling information, and expressing them as affine.for and affine.if operations in Affine Dialect.

2. The method according to claim 1, characterized in that, The Looplet dialect comes from the core language Looplet in the finch compiler.

3. The method according to claim 1, characterized in that, The scheduling optimization uses a polyhedral model to reschedule the execution order of loops, including: loop rearrangement, loop tiling, and loop merging.

4. The method according to claim 1, characterized in that, The parsing and construction of the affine dialect includes: affine.for operation, affine.if operation, affine.load operation, and affine.store operation.

5. An accelerator card operator adapter, characterized in that, The device includes: The input module is used to place the operator source code into a designated folder; The conversion module is used to convert the operator source code into an abstract syntax tree (AST). The processing module is used to generate a Looplet dialect based on the Abstract Syntax Tree (AST) using the MLIR tool; The first optimization module is used to optimize the accelerator card operators within the Looplet dialect according to the architecture of the accelerator card. The first conversion module is used to convert the Looplet dialect into an affine dialect using the MLIR tool; The second optimization module is used to optimize the accelerator card operator based on the affine dialect using a polyhedral model; The second conversion module is used to convert the affine dialect into the llvm dialect using the MLIR tool; The third conversion module is used to convert LLVM dialect to LLVM IR using LLVM tools; The compilation module is used to compile LLVM IR into executable binary files using the LLC tool under LLVM; The second optimization module is further configured to: parse and construct an affine dialect; analyze the dependencies between different loop iterations and array accesses using the AffineAnalysis tool; construct a graph structure to represent the dependencies; represent the iteration space of the affine.for loop in the process of parsing and constructing the affine dialect as a region in a polyhedron model; use the dependencies as constraints in the polyhedron model based on data dependency analysis; optimize scheduling by using the polyhedron model to reschedule the execution order of the loops; identify independent loop iterations and achieve parallel execution by generating affine.parallel; generate a new Affine Dialect IR; the generation of the new AffineDialect IR includes: remapping the iteration space and scheduling information, and expressing them as affine.for and affine.if operations in the Affine Dialect.

6. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images