Method and system for obtaining control flow graph representation of HIP kernel function basic block call relationship

Abstract

The application discloses a method and system for obtaining a control flow graph representation of a HIP kernel function basic block call relationship, extracts a kernel function of a HIP program and compiles the kernel function into an LLVM IR intermediate code, divides the kernel function into a plurality of basic blocks, allocates a unique serial number to each basic block, inserts a new edge basic block to represent a call relationship on a jump edge, generates a basic block level kernel function control flow graph, uses an LLVM insertion Pass to insert the newly added edge basic block, designs two light-weight thread insertion modes to reduce insertion overhead, the two light-weight thread insertion modes are ProfileCTA and ProfileWavefront, adopts a compilation process combining device end and host end insertion, runs on a domestic DCU platform, collects a call frequency between the basic blocks, takes the dynamic information as an edge weight of the CFG, and finally generates a basic block level HIP program kernel function CFG with dynamic information. The application effectively reduces the insertion overhead, improves the acquisition efficiency of the dynamic call relationship, and provides strong support for high-performance computing and program optimization.

Description

Technical Field

[0001] The present invention belongs to the technical field of compilation optimization and program performance analysis, and in particular relates to a control flow graph representation method and system for obtaining the calling relationship of basic blocks of a HIP kernel function. Background Art

[0002] In the field of high-performance computing (HPC), performance modeling is a key technology for optimizing and improving computing system efficiency. Accurately predicting program execution time to rationally allocate computing resources is a core task of performance modeling, particularly on supercomputing platforms. HIP, as a cross-platform programming model, is widely used in GPU computing. Since HIP programs run most efficiently and are widely used on domestic DCU platforms, we chose to build performance models for HIP programs.

[0003] A control flow graph (CFG) is a commonly used graphical model in program analysis. It intuitively represents a program's control flow structure through the relationships between nodes and edges. This graphical model effectively abstracts and simplifies the program's execution flow, thus supporting subsequent program performance modeling and analysis. By representing HIP programs as graphs for dynamic analysis, we can clearly capture the complex control flow relationships within the program, enabling in-depth identification of performance bottlenecks, memory access patterns, and control flow hotspots, providing a scientific basis for subsequent performance optimization and improvement.

[0004] Traditional static program analysis focuses primarily on identifying code structure and potential optimization opportunities, but it cannot fully reflect the dynamic behavior of a program at runtime. Therefore, static analysis methods have certain limitations and are generally lacking in accuracy and precision.

[0005] Currently, most research focuses on performance optimization for NVIDIA GPU platforms, employing the CUDA programming model and using PTX intermediate code for performance modeling. These approaches are often highly platform-dependent. However, HIP programs cannot be directly converted into PTX intermediate code, making performance modeling on this programming model challenging.

[0006] Furthermore, although many instrumentation analysis methods have achieved some success on GPUs, they usually rely on complex and comprehensive instrumentation techniques, resulting in high storage overhead and computational cost.

[0007] Among the existing LLVM IR graph representation tools, such as Programl, static graphs are constructed based on the instruction level. This method generates a large graph structure, has a slow processing speed, and occupies more memory resources. Summary of the Invention

[0008] The technical problems to be solved by the present application are to provide a method and system for obtaining a control flow graph representation of a HIP kernel function basic block call relationship, so as to solve the technical problems that the existing method cannot accurately capture the dynamic behavior of a HIP program, generate an efficient and lightweight control flow graph, and adapt to a domestic DCU platform for performance modeling.

[0009] The present application adopts the following technical solutions:

[0010] The method for obtaining a control flow graph representation of a HIP kernel function basic block call relationship comprises the following steps:

[0011] S1, extracting a kernel function of a HIP program, and compiling the kernel function into an LLVM IR intermediate code, the LLVM IR intermediate code dividing the kernel function into a plurality of basic blocks, each basic block containing an ordered instruction sequence;

[0012] S2, traversing the divided basic blocks, assigning a unique serial number to each basic block, and saving the call relationship between each basic block and its successor basic block, inserting a new basic block representing the call relationship into the jump edge between the basic block and its successor, as an edge basic block and assigning a unique serial number;

[0013] S3, constructing a basic block level kernel function control flow graph, each original basic block of the kernel function being added to the graph structure as a node, and adding a directed edge between the basic block and all its successor basic blocks according to the control flow relationship, the direction of the edge representing the direction of the program execution flow;

[0014] S4, inserting a call instruction to a counting function into the newly added edge basic block through an LLVM plug-in Pass, obtaining the plug-in LLVM IR code, and outputting the call number of the original basic block to its successor basic block during subsequent execution;

[0015] S5, designing a lightweight thread plug-in mode, the first mode analyzing only one CTA, and the second mode analyzing only one Wavefront;

[0016] S6, compiling and running the lightweight plug-in LLVM IR intermediate code, obtaining the call number between the basic blocks, collecting the execution number of each edge, and taking the obtained execution number as the weight of the edge in the control flow graph CFG, and generating a basic block level HIP program kernel function control flow graph CFG with dynamic information.

[0017] Preferably, step S2 is specifically:

[0018] S201, traversing all basic blocks in the LLVM IR code of the HIP program kernel function, assigning a unique serial number to each basic block, so as to distinguish the original basic block from the subsequently added edge basic block.

[0019] S202, save the calling relationship between each basic block and all its subsequent basic blocks;

[0020] S203, inserting a new basic block onto the jump edge of the basic block and its successor basic block to represent the calling relationship, which is called an edge basic block, and assigning a unique serial number to each newly inserted edge basic block;

[0021] S204 , traverse each newly inserted edge basic block, insert counting function call instructions only into the edge basic blocks, and obtain the calling relationship and calling times between the basic blocks when the instrumentation program is subsequently executed.

[0022] Preferably, the original basic blocks are named Block 1, Block 2 to Block n in sequence; each newly inserted edge basic block is assigned a unique serial number, and the edge basic blocks are named Edgei_j in sequence, indicating the edge basic block newly inserted on the jump edge between the original basic block Block i and its successor basic block Block j.

[0023] Preferably, in the control flow graph of step S3, each original basic block serves as a graph node, and each graph node uses the unique serial number of the basic block as an identifier; when adding directed edges, if a basic block has multiple successor basic blocks, a separate directed edge is added between each pair of basic blocks to form a complete branch structure; if the successor of a basic block contains itself or a predecessor path back to the basic block, a ring structure is formed.

[0024] Preferably, step S4 is specifically:

[0025] S401, extract the device-side kernel function and various information of the original IR code, clone the device-side kernel function and add the basic block list, bank number and instrumentation granularity;

[0026] S402. Obtain the LLVM IR code after inserting the edge basic block according to step S2.

[0027] S403, traverse all edge basic blocks and insert a counting function call statement at the beginning of each edge basic block;

[0028] S404: Generate instrumented LLVM IR code to implement lightweight instrumentation counting for edge basic blocks.

[0029] Preferably, in step S403 , the counting function includes a counter for storing the counting result of each basic block, the sequence number of the edge basic block, the number of banks, and the instrumentation granularity.

[0030] Preferably, in step S5, the lightweight thread instrumentation mode includes:

[0031] ProfileCTA: only one thread block CTA is profiled, and the thread block at the center of the thread block grid is selected;

[0032] ProfileWavefront: one wavefront is profiled, and all threads in the center wavefront of the center thread block are profiled.

[0033] Preferably, the basic block counts the number of calls to its successor basic block The definitions are as follows:

[0034]

[0035] Wherein, represents the grid size, represents the newly inserted edge basic block on the jump edge from the original basic block i to its successor basic block j, represents the edge basic block the counting size of the counting function, represents the thread block size, is the minimum number of threads scheduled and executed by the accelerator, represents the ProfileCTA thread profiling mode, represents the ProfileWavefront thread profiling mode.

[0036] Preferably, step S6 is specifically:

[0037] S601, the HIP program running on the domestic DCU platform is compiled by the hipcc compiler to generate a device-side LLVM IR file, and the instrumented device-side IR file is generated by the opt tool, and the instrumented device-side IR file and the device-side runtime file are linked by the llvm-link tool;

[0038] S602, compiled into a device-side binary file hipfb by the domestic DCU compiler dcc, the linker ld.lld and the clang-bundle, for calling by the host side;

[0039] S603, the host-side code must be compiled by dcc, and the device-side code is added to the host-side LLVM IR file by the -fcuda-include-gpubinary parameter;

[0040] S604, the same process as the device side is performed to obtain the overall LLVM IR file after device-side and host-side profiling, and the compiler dcc and the linker ld are used for compilation;

[0041] S605, traverse each original basic block of the HIP program kernel function, and add the original basic block as a node to the graph structure;

[0042] S606. Add directed edges between the basic block and all its successor basic blocks based on the control flow relationship. The direction of the edge represents the direction of the program execution flow.

[0043] S607: Collect the count size of each newly added edge basic block, and obtain the number of calls between basic blocks according to the set thread instrumentation mode;

[0044] S608: Add the number of calls of the basic block to its subsequent basic block as dynamic information into the CFG as the weight of the edge to generate the final HIP program kernel function control flow graph.

[0045] In a second aspect, an embodiment of the present invention provides a control flow graph representation system for obtaining a call relationship between basic blocks of a HIP kernel function, including:

[0046] Divide the module, extract the kernel function of the HIP program, and compile the kernel function into LLVM IR intermediate code. The LLVM IR intermediate code divides the kernel function into multiple basic blocks, each of which contains an ordered instruction sequence;

[0047] Traverse the module, traverse the divided basic blocks, assign a unique serial number to each basic block, save the calling relationship between each basic block and its successor basic block, insert a new basic block representing the calling relationship on the jump edge between the basic block and its successor as an edge basic block and assign a unique serial number;

[0048] Function module, builds the kernel function control flow graph at the basic block level. Each original basic block of the kernel function is added as a node to the graph structure. According to the control flow relationship, directed edges are added between the basic block and all its successor basic blocks. The direction of the edge represents the direction of the program execution flow.

[0049] The calling module inserts a call instruction to the counting function into the newly added edge basic block through the LLVM instrumentation pass, obtains the instrumented LLVM IR code, and outputs the number of calls made by the original basic block to its successor basic block during subsequent execution;

[0050] The output module designs lightweight thread instrumentation modes. The first mode analyzes only one CTA, and the second mode analyzes only one Wavefront. The lightweight instrumented LLVM IR intermediate code is compiled and run to obtain the number of calls between basic blocks. The execution count of each edge is collected and used as the edge weight in the control flow graph (CFG). This generates a basic block-level HIP program kernel function control flow graph (CFG) with dynamic information.

[0051] In a third aspect, a computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function are implemented.

[0052] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, comprising a computer program, which, when executed by a processor, implements the steps of the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function.

[0053] In a fifth aspect, a chip includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function are implemented.

[0054] In a sixth aspect, an embodiment of the present invention provides an electronic device, comprising a computer program, which, when executed by the electronic device, implements the steps of the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function.

[0055] Compared with the prior art, the present invention has at least the following beneficial effects:

[0056] A control flow graph representation method for capturing the call relationships of basic blocks of HIP kernel functions uses the number of dynamic calls obtained through lightweight instrumentation analysis as edge weights to generate a basic block-level HIP program kernel function CFG with dynamic information. This allows the control flow graph to reflect not only the static structure of the program but also its actual dynamic behavior during execution. Compared to traditional static analysis methods, this method can more accurately capture the actual execution of the program, providing a more accurate basis for subsequent performance modeling and more effectively identifying performance bottlenecks and hotspots. By simultaneously instrumenting the device and host on a domestic DCU platform and combining tools such as hipcc, opt, llvm-link, and dcc, the overall compilation and instrumentation process is streamlined. This process not only ensures the synchronization of device and host performance data but also improves the efficiency of the entire performance modeling and optimization process. It is suitable for large-scale parallel computing tasks, especially on high-performance computing platforms. The basic block-level control flow graph representation method significantly reduces the size of the graph structure, reduces memory usage, and increases graph processing speed. This enables the present invention to provide higher efficiency and lower resource consumption in large-scale computing tasks, especially on supercomputing platforms.

[0057] Furthermore, compared to traditional instruction-level static graph analysis methods like Program1, this paper designs a basic-block-level control flow graph representation method, which reduces the graph structure size by more than tenfold, significantly reduces memory usage, and significantly improves graph processing speed. This enables the present invention to provide higher efficiency and lower resource consumption in large-scale computing tasks, especially on supercomputing platforms.

[0058] Furthermore, by constructing a basic block-level control flow graph, uniquely identifying nodes and meticulously adding directed edges to fully describe branch and loop structures, this design reduces the size and redundancy of the graph structure, lowering memory usage and computational costs, and providing an accurate data foundation for performance modeling.

[0059] Furthermore, two lightweight thread instrumentation modes (ProfileCTA and ProfileWavefront) were designed to effectively reduce the storage and computational overhead of the instrumentation process. Furthermore, only newly inserted edge basic blocks are instrumented, further reducing the additional computational overhead associated with instrumentation analysis. Compared to traditional full analysis methods, these modes significantly reduce the additional cost of performance analysis without sacrificing analysis accuracy, which is particularly important in highly concurrent computing tasks.

[0060] Furthermore, this paper proposes an instrumentation method that simultaneously instruments both the device and host on a domestic DCU platform. Combining tools such as hipcc, opt, llvm-link, and dcc, this method streamlines and encapsulates the overall compilation and instrumentation process. This method not only ensures synchronization of device and host performance data but also significantly improves the efficiency of performance modeling and optimization.

[0061] It can be understood that the beneficial effects of the second aspect mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here.

[0062] In summary, the present invention effectively reduces instrumentation overhead, improves the efficiency of obtaining dynamic call relationships, and provides strong support for high-performance computing and program optimization.

[0063] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0065] Figure 1 is a flow chart of the present invention;

[0066] Figure 2 Schematic diagram of lightweight instrumentation counting for edge basic blocks;

[0067] Figure 3 The compilation flow chart of the HIP instrumentation program on the domestic DCU;

[0068] Figure 4 This is an example of the control flow graph of the HIP program kernel function at the basic block level;

[0069] Figure 5 A schematic diagram of a computer device provided in accordance with an embodiment of the present invention;

[0070] Figure 6 The present invention is a block diagram of an electronic device according to an embodiment of the present invention.

[0071] Among them, 60. Computer device; 61. Processor; 62. Memory; 63. Computer program; 600. Electronic device; 610. Processing unit; 620. Storage unit; 6201. Random access memory unit; 6202. Cache memory unit; 6203. Read-only memory unit; 6204. Program / Utility; 6205. Program module; 630. Bus; 640. Display unit; 650. Input / output interface; 660. Network adapter; 700. External device. DETAILED DESCRIPTION

[0072] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0073] In the description of the present invention, it is to be understood that the terms “include” and “comprise” indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or collections thereof.

[0074] It should also be understood that the terms used in the present specification are only for the purpose of describing particular embodiments and are not intended to limit the present invention. As used in the present specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0075] It should be further understood that the term "and / or" as used in the present specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in the present invention generally indicates that the associated objects are in an "or" relationship.

[0076] It should be understood that although the terms "first," "second," and "third" may be used to describe preset ranges in embodiments of the present invention, these preset ranges should not be limited to these terms. These terms are merely used to distinguish one preset range from another. For example, without departing from the scope of embodiments of the present invention, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0077] The word "if," as used herein, may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to the determination" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)," depending on the context.

[0078] The accompanying drawings illustrate various schematic diagrams of structures according to embodiments disclosed herein. These figures are not drawn to scale; for clarity, some details are exaggerated and some details may be omitted. The shapes of the various regions and layers shown in the figures, as well as their relative sizes and positional relationships, are merely exemplary and may deviate in practice due to manufacturing tolerances or technical limitations. Those skilled in the art may design regions / layers with different shapes, sizes, and relative positions as needed.

[0079] The application provides a method for obtaining a control flow graph representation of a HIP kernel function basic block call relationship, which comprises the following steps: first, extracting a kernel function of a HIP program and compiling the kernel function into an LLVM IR intermediate code, and dividing the kernel function into a plurality of basic blocks; assigning a unique serial number to each basic block, inserting a new edge basic block representing a call relationship on a jump edge, generating a basic block level kernel function control flow graph (CFG), using an LLVM instrumentation Pass to instrument only the newly added edge basic block, reducing the instrumentation range, designing two lightweight thread instrumentation modes to reduce the instrumentation overhead, namely ProfileCTA (analyzing a thread block) and ProfileWavefront (analyzing a Wavefront), and adopting a compilation process combining device-side and host-side instrumentation to run on a domestic DCU platform, collect the call times between the basic blocks, and use the dynamic information as the edge weight of the CFG, and finally generate a basic block level HIP program kernel function CFG with dynamic information. The application effectively reduces the instrumentation overhead, improves the efficiency of obtaining dynamic call relationships, and provides strong support for high-performance computing and program optimization.

[0080] Embodiment 1

[0081] Please refer to Figure 1 The application provides a method for obtaining a control flow graph representation of a HIP kernel function basic block call relationship, which comprises the following steps: first, extracting a kernel function of a HIP program and compiling the kernel function into an LLVM IR intermediate code, and dividing the kernel function into a plurality of basic blocks; assigning a unique serial number to each basic block, inserting a new edge basic block representing a call relationship on a jump edge, generating a basic block level kernel function control flow graph (CFG), using an LLVM instrumentation Pass to instrument only the newly added edge basic block, reducing the instrumentation range, designing two lightweight thread instrumentation modes to reduce the instrumentation overhead, namely ProfileCTA (analyzing a thread block) and ProfileWavefront (analyzing a Wavefront), and adopting a compilation process combining device-side and host-side instrumentation to run on a domestic DCU platform, collect the call times between the basic blocks, and use the dynamic information as the edge weight of the CFG, and finally generate a basic block level HIP program kernel function CFG with dynamic information. The application effectively reduces the instrumentation overhead, improves the efficiency of obtaining dynamic call relationships, and provides strong support for high-performance computing and program optimization.

[0082] S1, obtaining a HIP program running on a domestic DCU platform, extracting a kernel function of the HIP program, and compiling the kernel function into an LLVM IR intermediate code by using a compiler, wherein the intermediate code divides the kernel function into a plurality of basic blocks, and each basic block comprises an ordered instruction sequence;

[0083] The HIP program comprises host-side and device-side codes, the device-side kernel function of the HIP program is extracted by using a hipcc compiler, and is converted into an LLVM IR intermediate code with hardware independence.

[0084] S2, traversing the basic blocks, assigning a unique serial number to each basic block, saving the call relationship between each basic block and a subsequent basic block, inserting a new edge basic block representing a call relationship on a jump edge of the basic block and the subsequent basic block, and assigning a unique serial number to the newly inserted edge basic block;

[0085] Insert a new basic block onto the jump edge between the basic block and its successor basic block. Combined with step S4, insert a call to the counting function only in the newly created edge basic block to obtain the calling relationship of the kernel function of the HIP program at the basic block level, specifically including:

[0086] S201, traverse all basic blocks in the LLVM IR code of the HIP program kernel function, assign a unique serial number to each basic block, so as to distinguish the original basic block from the subsequently added edge basic blocks;

[0087] The basic blocks are named Block 1, Block 2 to Block n in sequence.

[0088] S202, save the calling relationship between each basic block and all its subsequent basic blocks;

[0089] The definition of a call relationship is based on control flow, referring to the target basic block to which the current basic block will jump after execution. This call relationship is represented by control flow edges between basic blocks and can describe the logical execution path of the program. For example, a basic block containing a conditional branch may have multiple successor basic blocks. The call relationships of all successor basic blocks need to be stored in a structured form to facilitate the subsequent construction of the control flow graph.

[0090] S203, inserting a new basic block onto the jump edge of the basic block and its successor basic block to represent the calling relationship, which is called an edge basic block, and assigning a unique serial number to each newly inserted edge basic block;

[0091] S204 , traverse each newly inserted edge basic block and insert counting function call instructions only into the edge basic block to reduce the scope of the insertion, so as to obtain the calling relationship and the number of calls between the basic blocks when the insertion program is subsequently executed.

[0092] The primary function of an edge basic block is to represent the control flow jump between the original basic block and the subsequent basic block. Edge basic blocks contain specific instructions, such as recording jump information and counting call counts, to support subsequent dynamic analysis.

[0093] Each newly inserted edge basic block also needs to be assigned a unique serial number, and the basic blocks are named Edgei_j in sequence, indicating the newly inserted edge basic block on the jump edge between the original basic block Block i and its successor basic block Block j.

[0094] S3. Construct the kernel function control flow graph CFG at the basic block level. Each original basic block of the kernel function is added as a node to the graph structure. According to the control flow relationship, directed edges are added between the basic block and all its successor basic blocks. The direction of the edge represents the direction of the program execution flow.

[0095] In the control flow graph, each original basic block is a graph node. Each node takes the unique sequence number of the basic block as an identifier to distinguish different basic blocks. The node contains the basic information of the basic block, such as the instruction sequence of the basic block. The inserted edge basic block is not added to the graph structure as a node.

[0096] When adding a directed edge, if there are multiple successor basic blocks for a basic block, a separate directed edge is added between each pair of basic blocks to form a complete branch structure representation. If the successor of a basic block contains itself or a certain predecessor path returns to the basic block, a loop will be formed in the control flow graph. When constructing the graph, the loop needs to be correctly included in the graph structure.

[0097] S4, through the LLVM instrumentation Pass, only the newly added edge basic block is inserted to call the counting function, and the instrumented LLVM IR code is obtained, so that the number of calls of the original basic block to its successor basic block can be output during subsequent execution;

[0098] Please refer to Figure 2 , the principle of lightweight instrumentation counting for edge basic blocks Figure 2 , the specific steps are as follows:

[0099] S401, extract the device-side kernel function of the original IR code and its various information, clone the device-side kernel function and add three new parameters, including: basic block list, bank number (to prevent write conflict) and instrumentation granularity;

[0100] S402, according to the process of step S2, the LLVM IR code after inserting the edge basic block is obtained;

[0101] S403, traverse all edge basic blocks, and insert a counting function call statement at the beginning of each edge basic block;

[0102] The counting function is responsible for tracking the execution of the basic block, so as to ensure that the counting operation is triggered at runtime.

[0103] The counting function should include the following 4 parameters: the counter for storing the counting results of each basic block, the sequence number of the edge basic block, the bank number and the instrumentation granularity.

[0104] S404, generate the instrumented LLVM IR code to realize lightweight instrumentation counting for edge basic blocks.

[0105] S5, design two lightweight thread instrumentation modes to reduce the instrumentation overhead, the first one is to analyze only one CTA, which belongs to medium overhead, and the second one is to analyze only one Wavefront, which has smaller overhead;

[0106] ProfileCTA: Instruments only one thread block CTA, selecting the thread block at the center of the thread block grid. The central thread block better represents the behavior of most threads, thus achieving a balance between profiling overhead and profiling accuracy. The overhead is medium.

[0107] ProfileWavefront: Only one Wavefront is analyzed. The Wavefront size applicable to the DTK software stack of the domestic DCU is 64. 64 threads are the minimum thread group scheduled and executed by the domestic DCU. All threads in the center Wavefront of the central thread block are selected for instrumentation analysis, which minimizes the overhead.

[0108] The reason for selecting the central thread block for analysis is that in some cases, threads at the edge of a 3D thread block are only used to load data into shared memory to assist other threads and do not participate in computations. These edge threads may behave differently from the majority of threads. Therefore, selecting the central thread block for analysis more accurately represents the behavior of the majority of threads. The same principle applies to the central Wavefront of the central thread block.

[0109] In the above two lightweight thread instrumentation modes, the number of times a basic block calls its successor basic block is calculated using the following formula: The definition is as follows:

[0110]

[0111] in, Indicates the grid size, which is the number of thread blocks in the x, y, and z directions. represents the newly inserted edge basic block on the jump edge between the original basic block i and its successor basic block j. Represents edge basic blocks The count size of the counting function in , Indicates the thread block size, which is the number of threads in a thread block in the x, y, and z directions. It is the minimum number of threads scheduled and executed by the accelerator. is 64, Indicates that ProfileCTA thread instrumentation mode is used. Indicates that ProfileWavefront thread instrumentation mode is used.

[0112] S6. Compile and run the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks. This is used to collect the execution count of each edge and use these execution counts as the weight of the edge in the CFG. This generates a basic block-level HIP program kernel function control flow graph (CFG) with dynamic information.

[0113] See also Figure 3 , which is the compilation flow chart of the HIP instrumentation program on the domestic DCU. On the domestic DCU platform, the overall compilation process of the HIP program to be lightweight instrumented is performed on both the device side and the host side at the same time as follows:

[0114] S601. Generate the device-side LLVM IR file using the hipcc compiler for the HIP program running on the domestic DCU platform, generate the instrumented device-side IR file using the opt tool, and then link the instrumented device-side IR file and the device-side runtime file using the llvm-link tool.

[0115] S602, compiled into the device-side binary file hipfb by the domestic DCU compiler dcc, linker ld.lld and clang-bundle for host-side calling;

[0116] S603. The host code must be compiled using dcc and the -fcuda-include-gpubinary parameter must be used to add the device code to the host LLVM IR file.

[0117] S604: Execute the same process as the device side again to obtain the overall LLVMIR file after the device side and host side are instrumented. Finally, compile through the compiler dcc and the linker ld to generate an executable file.

[0118] See also Figure 4 , which is a specific example of a basic block-level HIP program kernel function control flow graph. Combined with step S3, a basic block-level HIP program kernel function control flow graph CFG with dynamic information is generated, specifically including:

[0119] S605, traverse each original basic block of the HIP program kernel function, and add the original basic block as a node to the graph structure;

[0120] S606. Add directed edges between the basic block and all its successor basic blocks based on the control flow relationship. The direction of the edge represents the direction of the program execution flow.

[0121] S607: Run the executable file to collect the count size in each newly added edge basic block, and obtain the number of calls between basic blocks according to the set thread instrumentation mode;

[0122] S608: Add the number of calls of the basic block to its subsequent basic block as dynamic information into the CFG as the weight of the edge, thereby generating the final HIP program kernel function control flow graph.

[0123] Those skilled in the art can understand that various aspects of the present application can be implemented as a system, a method or a program product. Therefore, various aspects of the present application can be embodied as a complete hardware embodiment, a complete software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, which can be collectively referred to as "circuitry", "module" or "platform" here.

[0124] Embodiment 2

[0125] The present application provides a system for obtaining a control flow graph representation of a HIP kernel function basic block call relationship, which can be used to implement the above-mentioned method for obtaining a control flow graph representation of a HIP kernel function basic block call relationship. Specifically, the system for obtaining a control flow graph representation of a HIP kernel function basic block call relationship comprises a division module, a traversal module, a function module, a call module and an output module.

[0126] The division module extracts the kernel function of the HIP program and compiles the kernel function into LLVM IR intermediate code. The LLVM IR intermediate code divides the kernel function into a plurality of basic blocks, and each basic block contains an ordered instruction sequence.

[0127] The traversal module traverses the divided basic blocks, assigns a unique serial number to each basic block, and saves the call relationship between each basic block and its successor basic block. A new basic block representing the call relationship is inserted into the jump edge between the basic block and its successor, which is called an edge basic block and is assigned a unique serial number.

[0128] The function module constructs a basic block-level kernel function control flow graph. Each original basic block of the kernel function is added as a node to the graph structure. According to the control flow relationship, a directed edge is added between the basic block and all its successor basic blocks. The direction of the edge represents the direction of the program execution flow.

[0129] The call module inserts a call instruction to the counting function into the newly added edge basic block through the LLVM instrumentation Pass, obtains the instrumented LLVM IR code, and outputs the call count of the original basic block to its successor basic block during subsequent execution.

[0130] The output module designs a lightweight thread instrumentation mode. The first mode only analyzes one CTA, and the second mode only analyzes one Wavefront. The LLVM IR intermediate code after lightweight instrumentation is compiled and run to obtain the call count between basic blocks. The execution count of each edge is collected, and the obtained execution count is used as the weight of the edge in the control flow graph CFG. A basic block-level HIP program kernel function control flow graph CFG with dynamic information is generated.

[0131] Embodiment 3

[0132] The present invention provides a terminal device, which includes a processor and a memory, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is used to execute the program instructions stored in the computer storage medium. The processor may be a central processing unit (CPU), or may be other general-purpose processors, graphics processing units (GPUs), tensor processing units (TPUs), digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. It is the computing core and control core of the terminal, which is suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions to implement corresponding method processes or corresponding functions; the processor described in the embodiment of the present invention can be used to obtain the control flow graph representation method of the HIP kernel function basic block call relationship, including:

[0133] Extract the kernel function of the HIP program and compile it into LLVM IR intermediate code. The LLVM IR intermediate code divides the kernel function into multiple basic blocks, each of which contains an ordered sequence of instructions. Traverse the divided basic blocks, assign a unique serial number to each basic block, and save the calling relationship between each basic block and its successor basic block. Insert a new basic block representing the calling relationship on the jump edge between the basic block and its successor as an edge basic block and assign it a unique serial number. Construct a basic block-level kernel function control flow graph. Each original basic block of the kernel function is added to the graph structure as a node. According to the control flow relationship, directed edges are added between the basic block and all its successor basic blocks. The direction of the edge represents the direction of program execution flow. Through the LLVM instrumentation pass, a call instruction to the counting function is inserted into the newly added edge basic block to obtain the instrumented LLVM IR code. During subsequent execution, the number of calls from the original basic block to its successor basic block is output. Design lightweight thread instrumentation modes. The first mode only analyzes one CTA, and the second mode only analyzes one Wavefront. Compile and run the lightweight instrumented LLVM The IR intermediate code obtains the number of calls between basic blocks, collects the execution count of each edge, and uses the obtained execution count as the weight of the edge in the control flow graph CFG to generate a basic block-level HIP program kernel function control flow graph CFG with dynamic information.

[0134] See also Figure 5 The terminal device is a computer device. The computer device 60 of this embodiment includes: a processor 61, a memory 62, and a computer program 63 stored in the memory 62 and executable by the processor 61. When the computer program 63 is executed by the processor 61, it implements the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function in the embodiment. To avoid repetition, it is not described in detail here. Alternatively, when the computer program 63 is executed by the processor 61, it implements the functions of each model / unit in the control flow graph representation system for obtaining the calling relationship of the basic blocks of the HIP kernel function in the embodiment. To avoid repetition, it is not described in detail here.

[0135] The computer device 60 may be a desktop computer, a notebook computer, a PDA, a cloud server, or other computing devices. The computer device 60 may include, but is not limited to, a processor 61 and a memory 62. It will be understood by those skilled in the art that Figure 5 This is merely an example of the computer device 60 and does not constitute a limitation of the computer device 60 . The computer device 60 may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device may also include input and output devices, network access devices, buses, etc.

[0136] The processor 61 may be a central processing unit (CPU), or other general-purpose processors, a graphics processing unit (GPU), a tensor processing unit (TPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0137] The memory 62 may be an internal storage unit of the computer device 60, such as a hard disk or memory of the computer device 60. The memory 62 may also be an external storage device of the computer device 60, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 60.

[0138] Furthermore, the memory 62 may include both an internal storage unit of the computer device 60 and an external storage device. The memory 62 is used to store computer programs and other programs and data required by the computer device. The memory 62 may also be used to temporarily store data that has been output or is about to be output.

[0139] See also Figure 6 The terminal device is an electronic device 600, which is implemented as a general-purpose computing device. The components of the electronic device may include, but are not limited to, at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including the storage unit 620 and the processing unit 610), and a display unit 640.

[0140] The storage unit stores program codes, which can be executed by the processing unit 610, so that the processing unit 610 performs the steps according to various exemplary embodiments of the present invention described in the above method section of this specification. For example, the processing unit 610 can perform the following steps: Figure 1 Follow the steps shown in .

[0141] The storage unit 620 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 6201 and / or a cache memory unit 6202 , and may further include a read-only memory unit (ROM) 6203 .

[0142] The storage unit 620 may also include a program / utility 6204 having a set (at least one) of program modules 6205, such program modules 6205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0143] Bus 630 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0144] The electronic device 600 can also communicate with one or more external devices 700 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 600, and / or any device that enables the electronic device 600 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output interface 650. Furthermore, the electronic device 600 can communicate with one or more networks (e.g., a local area network, a wide area network, and / or a public network such as the Internet) via a network adapter 660. The network adapter 660 can communicate with other modules of the electronic device 600 via the bus 630. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 600, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0145] Example 4

[0146] The present invention also provides a storage medium, specifically a computer-readable storage medium. The computer-readable storage medium is a memory device in a terminal device, used to store programs and data. It is understood that the computer-readable storage medium herein may include both the built-in storage medium in the terminal device and, of course, the extended storage medium supported by the terminal device. It may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. The computer-readable storage medium provides storage space that stores the terminal's operating system. Furthermore, the storage space also stores one or more instructions suitable for being loaded and executed by a processor. These instructions may be one or more computer programs (including program code). It should be noted that more specific examples of the computer-readable storage medium herein include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0147] Computer-readable storage media also include data signals propagated in baseband or as part of a carrier wave, which carry readable program code. Such propagated data signals can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable storage medium can also be any readable medium other than a readable storage medium, which can send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, device, or device. The program code contained on the readable storage medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, radio frequency, etc., or any suitable combination of the above.

[0148] The program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network or a wide area network, or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0149] The processor may load and execute one or more instructions stored in a computer-readable storage medium to implement the corresponding steps of the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function in the above embodiment; the processor may load and execute the following steps:

[0150] The kernel function of the HIP program is extracted, and the kernel function is compiled into LLVM IR intermediate code, the LLVM IR intermediate code divides the kernel function into a plurality of basic blocks, each basic block internally contains an ordered instruction sequence; the divided basic blocks are traversed, a unique serial number is allocated to each basic block, and the calling relationship between the basic blocks and the successor basic blocks is saved, a new basic block representing the calling relationship is inserted on the jump edge of the basic block and the successor, as an edge basic block and a unique serial number is allocated; a basic block level kernel function control flow graph is constructed, each original basic block of the kernel function is added to the graph structure as a node, a directed edge is added between the basic block and all the successor basic blocks according to the control flow relationship, and the direction of the edge represents the direction of the program execution flow; the inserted edge basic block is inserted with a calling instruction to the counting function through the LLVM plug-in Pass, the LLVM IR code after the plug-in is obtained, and the calling times of the original basic block to the successor basic block are output during subsequent execution; a lightweight thread plug-in mode is designed, the first mode only analyzes one CTA, and the second mode only analyzes one Wavefront; the LLVM IR intermediate code after the lightweight plug-in is compiled and run, the calling times between the basic blocks are obtained, the execution times of each edge are collected, and the obtained execution times are taken as the weights of the edges in the control flow graph CFG, and a basic block level HIP program kernel function control flow graph CFG with dynamic information is generated.

[0151] To make the objects, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0152] A basic block level control flow graph (CFG) with dynamic information is constructed by performing lightweight plug-in analysis on the HIP program running on the domestic DCU platform. This experiment will be divided into several steps, involving the compilation of LLVM IR intermediate code, the division of basic blocks, the plug-in of edge basic blocks, and dynamic analysis.

[0153] Step 1: Obtain the HIP program and convert it into LLVM IR

[0154] Obtain the HIP program: Obtain the HIP program on the target domestic DCU platform, which includes the host code and the device code.

[0155] Use the hipcc compiler: Use the hipcc compiler to extract the device-side kernel functions of the HIP program and convert them into LLVM IR intermediate code, ensuring that the intermediate code is independent of the hardware architecture for subsequent analysis.

[0156] Basic block division: Extract the kernel function from the compiled LLVM IR code and divide it into basic blocks. Each basic block will be uniquely numbered (Block 1, Block 2, ...).

[0157] Step 2: Generate basic block call relationship

[0158] Save call relationships: Traverse all basic blocks and record the call relationships between each basic block and all subsequent basic blocks. The call relationship is the jump path between basic block control flows.

[0159] Insert edge basic blocks: For each jump relationship between a basic block and its successor, insert a newly created edge basic block. Assign a unique number (Edge1_2) to each newly inserted edge basic block.

[0160] Lightweight instrumentation: Insert a call instruction to a counting function into the newly inserted edge basic block to record the number of jumps between basic blocks.

[0161] Step 3: Build the Control Flow Graph (CFG)

[0162] Build the graph structure: Add all original basic blocks as nodes to the control flow graph and save the instruction sequence of each basic block.

[0163] Add directed edges: Based on the recorded basic block call relationships, add directed edges between each pair of basic blocks. The direction of the edge represents the execution flow of the program, forming a complete control flow.

[0164] Handle loops and cycles: If the program has loops, ensure that the loop paths are handled in the graph and correctly reflect the execution order of basic blocks.

[0165] Step 4: Instrument LLVM IR

[0166] Insert counting function: Perform lightweight instrumentation on the newly inserted edge basic block, insert the call of the counting function, and track the number of basic block executions.

[0167] Generate instrumented LLVM IR: The final generated LLVM IR code will include count function call instructions, which will be used to track the number of calls to each edge basic block.

[0168] Step 5: Lightweight thread instrumentation mode

[0169] ProfileCTA: Instruments only one thread block (CTA), selecting the thread block at the center of the grid for analysis. This approach balances overhead and accuracy.

[0170] ProfileWavefront: Analyzes only one Wavefront and selects the central thread within the Wavefront in the thread block for instrumentation analysis to reduce instrumentation overhead.

[0171] The number of calls between a basic block and its successor basic blocks is calculated using a formula and different instrumentation modes (ProfileCTA or ProfileWavefront).

[0172] Step 6: Execute and collect dynamic information

[0173] Execute the instrumented code: Compile and run the instrumented LLVM IR code and collect the execution counts between basic blocks.

[0174] Construct a control flow graph with dynamic information: Based on the collected dynamic execution data (number of calls), update the edge weights of the control flow graph and generate the final basic block-level control flow graph with dynamic information.

[0175] Simulation experiment data analysis and result display

[0176] Visualization of the control flow graph: A graphical tool is used to display the basic block-level control flow graph. Each basic block is a node, and the connected directed edges represent the direction of the control flow. The edge weight represents the number of executions.

[0177] By comparing the overhead and accuracy of different instrumentation modes, we can optimize the instrumentation strategy and select the most suitable analysis method.

[0178] By dynamically analyzing HIP programs, we construct a control flow graph with dynamic information and reduce performance overhead through lightweight instrumentation. By analyzing the control flow between each basic block and subsequent basic blocks, combined with different instrumentation modes, we obtain accurate execution information and optimize the execution efficiency of kernel functions.

[0179] In summary, the present invention provides a control flow graph representation method and system for capturing the call relationships between basic blocks of a HIP kernel function. This method uses lightweight instrumentation analysis to obtain the number of dynamic calls between basic blocks and uses this information as edge weights in the control flow graph. This generates a basic block-level CFG with dynamic information, accurately reflecting the dynamic behavior of the program, providing an accurate basis for performance modeling and effectively identifying performance bottlenecks and hotspots. Two lightweight instrumentation modes (ProfileCTA and ProfileWavefront) are designed, and only newly inserted edge basic blocks are instrumented, significantly reducing instrumentation overhead. By integrating the device-side and host-side instrumentation processes of a domestic DCU platform and utilizing tools such as hipcc and opt to optimize the compilation and instrumentation processes, the efficiency of performance data collection is improved. The present invention reduces graph size and memory usage through basic block-level graph representation, improving graph processing efficiency. This method is suitable for large-scale parallel computing tasks on supercomputing platforms, providing efficient support for subsequent program performance modeling and analysis.

[0180] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0181] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0182] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0183] In the embodiments of the present application, it should be understood that the disclosed apparatus / terminal and method can be implemented in other manners. For example, the embodiments of the apparatus / terminal described above are merely schematic, and the division of the modules or units is merely logical function division, and there can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different units, can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0184] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0185] In addition, each functional unit in the various embodiments of the present application can be integrated into a processing unit, or each unit can be a physically independent unit, or two or more units can be integrated into a unit. The integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0186] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by computer programs instructing related hardware, and the computer programs can be stored in a computer readable storage medium. When the processor executes the computer programs, the steps of the above-mentioned various method embodiments can be implemented. The computer programs include computer program codes, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program codes, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the contents of the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0187] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices, and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0188] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0190] The above content is only for explaining the technical idea of ​​the present invention and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution in accordance with the technical idea proposed by the present invention shall fall within the protection scope of the claims of the present invention.

Claims

1. A control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function, characterized in that: The following steps are involved: S1. Extract the kernel function of the HIP program and compile it into LLVM IR intermediate code. The LLVM IR intermediate code divides the kernel function into multiple basic blocks, each of which contains an ordered instruction sequence. S2. Traverse the divided basic blocks, assign a unique sequence number to each basic block, save the calling relationship between each basic block and its successor basic block, and insert a new basic block representing the calling relationship on the jump edge between the basic block and its successor as an edge basic block and assign a unique sequence number. S3. Construct a basic block-level kernel function control flow graph. Each original basic block of the kernel function is added as a node to the graph structure. Directed edges are added between the basic block and all its successor basic blocks based on the control flow relationship. The direction of the edge indicates the direction of program execution flow. Each original basic block is a graph node, and each graph node uses the basic block's unique serial number as an identifier. When adding directed edges, if a basic block has multiple successor basic blocks, a separate directed edge is added between each pair of basic blocks to form a complete branching structure. If a basic block's successor contains itself or a predecessor path back to the basic block, a ring structure is formed. S4. Insert a call instruction to the counting function into the newly added edge basic block through the LLVM instrumentation pass, obtain the instrumented LLVM IR code, and output the number of calls made by the original basic block to its successor basic block during subsequent execution. S5. Design lightweight thread instrumentation modes. The first mode only analyzes one CTA, and the second mode only analyzes one Wavefront. The lightweight thread instrumentation modes include: ProfileCTA: Instruments only one thread block CTA, selecting the thread block at the center of the thread block grid; ProfileWavefront: Analyze a Wavefront, select all threads in the center Wavefront of the central thread block for instrumentation analysis, and count the number of calls from the basic block to its successor basic block. The definition is as follows: in, represents the grid size, represents the newly inserted edge basic block on the jump edge between the original basic block i and its successor basic block j. Represents edge basic blocks The count size of the counting function in , Indicates the thread block size, is the minimum number of threads scheduled and executed by the accelerator, Indicates that ProfileCTA thread instrumentation mode is used. Indicates that ProfileWavefront thread instrumentation mode is used; S6. Compile and run the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks, collect the execution count of each edge, and use the obtained execution count as the weight of the edge in the control flow graph (CFG). This generates a basic block-level HIP program kernel function control flow graph (CFG) with dynamic information.

2. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 1 is characterized in that: Step S2 is specifically as follows: S201, traverse all basic blocks in the LLVM IR code of the HIP program kernel function, assign a unique serial number to each basic block, so as to distinguish the original basic block from the subsequently added edge basic blocks; S202, save the calling relationship between each basic block and all its subsequent basic blocks; S203, inserting a new basic block onto the jump edge of the basic block and its successor basic block to represent the calling relationship, which is called an edge basic block, and assigning a unique serial number to each newly inserted edge basic block; S204 , traverse each newly inserted edge basic block, insert counting function call instructions only into the edge basic blocks, and obtain the calling relationship and calling times between the basic blocks when the instrumentation program is subsequently executed.

3. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 2 is characterized in that: The original basic blocks are named Block 1, Block 2 to Block n in sequence; each newly inserted edge basic block is assigned a unique serial number, and the edge basic blocks are named Edgei_j in sequence, indicating the edge basic block newly inserted on the jump edge between the original basic block Block i and its successor basic block Block j.

4. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 1 is characterized in that: Step S4 is specifically as follows: S401, extract the device-side kernel function and various information of the original IR code, clone the device-side kernel function and add the basic block list, bank number and instrumentation granularity; S402. Obtain the LLVM IR code after inserting the edge basic block according to step S2. S403, traverse all edge basic blocks and insert a counting function call statement at the beginning of each edge basic block; S404: Generate instrumented LLVM IR code to implement lightweight instrumentation counting for edge basic blocks.

5. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 4 is characterized in that: In step S403 , the counting function includes a counter for storing the counting result of each basic block, the sequence number of the edge basic block, the number of banks, and the instrumentation granularity.

6. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 1, characterized in that: Step S6 is specifically as follows: S601. Generate the device-side LLVM IR file using the hipcc compiler for the HIP program running on the domestic DCU platform, generate the instrumented device-side IR file using the opt tool, and then link the instrumented device-side IR file and the device-side runtime file using the llvm-link tool. S602, compiled into the device-side binary file hipfb by the domestic DCU compiler dcc, linker ld.lld and clang-bundle for host-side calling; S603. The host code must be compiled using dcc and the -fcuda-include-gpubinary parameter must be used to add the device code to the host LLVM IR file. S604: Execute the same process as the device side again to obtain the overall LLVM IR file after the device side and host side instrumentation, and complete the compilation through the compiler dcc and the linker ld to generate an executable file; S605, traverse each original basic block of the HIP program kernel function, and add the original basic block as a node to the graph structure; S606. Add directed edges between the basic block and all its successor basic blocks based on the control flow relationship. The direction of the edge represents the direction of the program execution flow. S607: Run the executable file to collect the count size in each newly added edge basic block, and obtain the number of calls between basic blocks according to the set thread instrumentation mode; S608: Add the number of calls of the basic block to its subsequent basic block as dynamic information into the CFG as the weight of the edge to generate the final HIP program kernel function control flow graph.

7. A control flow graph representation system for obtaining the calling relationship of basic blocks of HIP kernel functions, characterized in that: include: Divide the module, extract the kernel function of the HIP program, and compile the kernel function into LLVM IR intermediate code. The LLVM IR intermediate code divides the kernel function into multiple basic blocks, each of which contains an ordered instruction sequence; Traverse the module, traverse the divided basic blocks, assign a unique serial number to each basic block, save the calling relationship between each basic block and its successor basic block, insert a new basic block representing the calling relationship on the jump edge between the basic block and its successor as an edge basic block and assign a unique serial number; Function module, builds the basic block-level kernel function control flow graph. Each original basic block of the kernel function is added as a node to the graph structure. Based on the control flow relationship, directed edges are added between the basic block and all its successor basic blocks. The direction of the edge indicates the direction of program execution flow. Each original basic block is a graph node, and each graph node uses the basic block's unique serial number as an identifier. When adding directed edges, if a basic block has multiple successor basic blocks, a separate directed edge is added between each pair of basic blocks to form a complete branch structure. If the successor of a basic block contains itself or a predecessor path back to the basic block, a ring structure is formed; The calling module inserts a call instruction to the counting function into the newly added edge basic block through the LLVM instrumentation pass, obtains the instrumented LLVM IR code, and outputs the number of calls made by the original basic block to its successor basic block during subsequent execution; The output module is designed with lightweight thread instrumentation modes. The first mode only analyzes one CTA, and the second mode only analyzes one Wavefront. The lightweight thread instrumentation modes include: ProfileCTA: Instruments only one thread block CTA, selecting the thread block at the center of the thread block grid; ProfileWavefront: Analyze a Wavefront, select all threads in the center Wavefront of the central thread block for instrumentation analysis, and count the number of calls from the basic block to its successor basic block. The definition is as follows: in, represents the grid size, represents the newly inserted edge basic block on the jump edge between the original basic block i and its successor basic block j. Represents edge basic blocks The count size of the counting function in , Indicates the thread block size, is the minimum number of threads scheduled and executed by the accelerator, Indicates that ProfileCTA thread instrumentation mode is used. Indicates the use of ProfileWavefront thread instrumentation mode; compiles and runs the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks, collects the execution count of each edge, and uses the obtained execution count as the edge weight in the control flow graph (CFG). This generates a basic block-level HIP program kernel function control flow graph (CFG) with dynamic information.

Images