Control flow graph representation method and system for obtaining basic block calling relation of HIP kernel function

Abstract

The invention discloses a control flow graph representation method and system for obtaining a basic block calling relation of an HIP kernel function, and the method comprises the steps: extracting the kernel function of an HIP program, compiling the kernel function into an LLVM IR intermediate code, and dividing the kernel function into a plurality of basic blocks; a unique serial number is distributed to each basic block, and a new edge basic block is inserted into the jump edge to represent the calling relation; generating a kernel function control flow diagram of a basic block level; the LLVM is used for instrumenting Pass, and instrumentation is carried out on the newly-added edge basic blocks; the method comprises the following steps: designing two lightweight thread instrumentation modes to reduce the instrumentation overhead, namely ProfileCTA and ProfileWavefront; the method comprises the following steps of: operating on a domestic DCU (Data Communication Unit) platform by adopting a compiling process of combining instrumentation of an equipment end and a host end, collecting calling times among basic blocks, taking dynamic information as an edge weight of CFG, and finally generating a basic-block-level HIP program kernel function CFG with the dynamic information. According to the method, the instrumentation overhead is effectively reduced, the obtaining efficiency of the dynamic calling relation is improved, and powerful support is provided for high-performance calculation and program optimization.

Description

Background Art

[0002] In the field of high-performance computing (HPC), performance modeling is a key technology for optimizing and improving the efficiency of computing systems. Especially on supercomputing platforms, how to accurately predict the execution time of programs in order to reasonably allocate computing resources is one of the core tasks of performance modeling. As a cross-platform programming model, HIP is widely used in GPU computing. Since HIP programs run most efficiently and are widely used on domestic DCU platforms, we choose to build a performance model for HIP programs.

[0003] Control flow graph (CFG) is a commonly used graph model in program analysis, which intuitively represents the control flow structure of the program through the relationship between nodes and edges. This graph model can effectively abstract and simplify the execution process of the program, thereby providing support for subsequent program performance modeling and analysis. By representing the HIP program as a graph structure for dynamic analysis, it is possible to clearly capture the complex control flow relationship in the program, and then deeply identify performance bottlenecks, memory access patterns, and hot spots in the control flow, providing a scientific basis for subsequent performance optimization and improvement.

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

[0005] Currently, most studies focus on performance optimization of NVIDIA GPU platforms, using the CUDA programming model and PTX intermediate code for performance modeling. These methods are usually highly platform-dependent. However, HIP programs cannot be directly converted to PTX intermediate code, which makes performance modeling on this programming model more 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, a static graph based on the instruction level is constructed. This method generates a larger graph structure, has a slower processing speed and occupies more memory resources. Summary of the invention

[0008] The technical problem to be solved by the present invention is to provide a control flow graph representation method and system for obtaining the calling relationship of the basic blocks of the HIP kernel function in view of the deficiencies in the above-mentioned prior art, so as to solve the technical problems that the existing methods cannot accurately capture the dynamic behavior of the HIP program, generate efficient and lightweight control flow graphs, and perform performance modeling for the subsequent adaptation of the domestic DCU platform.

[0009] The present invention adopts the following technical solutions: A method for obtaining a control flow graph representation of a basic block call relationship of a HIP kernel function includes the following steps: S1. 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. S2, 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 into the jump edge between the basic block and its successor as an edge basic block and assign a unique serial number; S3. 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. Directed edges are added between the basic block and all its successor basic blocks according to the control flow relationship. The direction of the edge indicates the direction of the program execution flow. 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 of the original basic block to its successor basic block during subsequent execution. S5. Design lightweight thread instrumentation modes. The first one only analyzes one CTA, and the second one only analyzes one Wavefront. S6. Compile and run the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks, collect the number of executions of each edge, and use the obtained number of executions 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.

[0010] Preferably, step S2 specifically includes: S201, traverse all basic blocks in the LLVM IR code of the HIP program kernel function, and assign a unique serial number to each basic block, so as to distinguish the original basic block from the subsequent newly added edge basic block; S202, save the calling relationship between each basic block and all its subsequent basic blocks; S203, inserting a new basic block to 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 block, and obtain the calling relationship and calling times between the basic blocks when the stub program is subsequently executed.

[0011] 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.

[0012] 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 includes itself or a predecessor path back to the basic block, a ring structure is formed.

[0013] Preferably, step S4 is specifically: 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 stub granularity; S402, obtaining 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 the instrumented LLVM IR code to implement lightweight instrumentation counting for edge basic blocks.

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

[0015] Preferably, in step S5, the lightweight thread instrumentation mode includes: ProfileCTA: Only one thread block CTA is instrumented, and the thread block at the center of the thread block grid is selected; ProfileWavefront: Analyze a Wavefront and select all threads in the center Wavefront of the center thread block for instrumentation analysis.

[0016] Preferably, the number of calls from a basic block to its successor basic block is The definition is as follows:

[0017] 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.

[0018] Preferably, step S6 specifically includes: S601, generate the LLVM IR file of the device side through the hipcc compiler for the HIP program running on the domestic DCU platform, generate the instrumented device side IR file through the opt tool, and then link the instrumented device side IR file and the device side runtime file through the llvm-link tool; S602, compiled into a 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 device code must be added to the host LLVM IR file using the -fcuda-include-gpubinary parameter; S604, executing the same process as the device side, obtaining the overall LLVMIR file after the device side and the host side are plugged in, and completing the compilation through the compiler dcc and the linker ld; 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, adding directed edges between the basic block and all its subsequent basic blocks according to the control flow relationship, where the direction of the edge indicates the direction of the program execution flow; S607, collecting the count size in each newly added edge basic block, and obtaining 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, and generate the final HIP program kernel function control flow graph.

[0019] 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: 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; The traversal module traverses the divided basic blocks, assigns a unique serial number to each basic block, and saves the calling relationship between each basic block and its successor basic block. A new basic block representing the calling relationship is inserted into the jump edge between the basic block and its successor as an edge basic block and is assigned a unique serial number. Function module, builds the kernel function control flow graph at the basic block level. 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 indicates the direction of the program execution flow. The calling module inserts the call instruction of the counting function into the newly added edge basic block through the LLVM instrumentation Pass, obtains the LLVM IR code after instrumentation, and outputs the number of calls of the original basic block to its successor basic block during subsequent execution; Output module, design lightweight thread instrumentation modes, the first one only analyzes one CTA, the second one only analyzes one Wavefront; compile and run the lightweight instrumented LLVM IR intermediate code, get the number of calls between basic blocks, collect the number of executions of each edge, and use the obtained execution number as the weight of the edge in the control flow graph CFG, and generate a basic block-level HIP program kernel function control flow graph CFG with dynamic information.

[0020] 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, wherein 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.

[0021] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, including 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.

[0022] In a fifth aspect, a chip includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein 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.

[0023] In a sixth aspect, an embodiment of the present invention provides an electronic device, including 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.

[0024] Compared with the prior art, the present invention has at least the following beneficial effects: A control flow graph representation method for obtaining the basic block call relationship of a HIP kernel function is used. The number of dynamic calls obtained by lightweight plug-in analysis is used as the weight of the edge to generate a HIP program kernel function CFG at the basic block level with dynamic information, so that the control flow graph not only reflects the static structure of the program, but also reflects the actual dynamic behavior of the program during execution. Compared with the traditional static analysis method, it can more accurately capture the actual execution of the program, provide a more accurate basis for subsequent performance modeling, and more effectively identify performance bottlenecks and hot spots. By plugging the device side and the host side on the domestic DCU platform at the same time, and combining tools such as hipcc, opt, llvm-link, and dcc, the overall compilation and plug-in process is streamlined. This process not only ensures the synchronization of performance data between the device side and the host side, 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. Through the control flow graph representation method at the basic block level, the scale of the graph structure is significantly reduced, the memory occupancy is reduced, and the graph processing speed is improved. This enables the present invention to provide higher efficiency and lower resource consumption in large-scale computing tasks, especially on supercomputing platforms.

[0025] Furthermore, compared with traditional static graph analysis methods based on instruction level such as Program1, the present invention designs a control flow graph representation method based on basic block level, which reduces the scale of graph structure by more than ten times, greatly 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.

[0026] Furthermore, by constructing a basic block-level control flow graph, identifying nodes with unique serial numbers, and adding directed edges in detail, the branch and loop structures are fully described. This design reduces the scale and redundancy of the graph structure, reduces memory usage and computing costs, and provides an accurate data foundation for performance modeling.

[0027] Furthermore, two lightweight thread instrumentation modes (ProfileCTA and ProfileWavefront) are designed to effectively reduce the storage and computational overhead during the instrumentation process. At the same time, only newly inserted edge basic blocks are instrumented, further reducing the additional computational overhead caused by instrumentation analysis. Compared with traditional full analysis methods, the use of these modes can significantly reduce the additional cost of performance analysis without sacrificing analysis accuracy, which is particularly important in high-concurrency computing tasks.

[0028] Furthermore, the present invention proposes a plugging method, which plugs both the device side and the host side on the domestic DCU platform, and simplifies and encapsulates the overall compilation and plugging process by combining tools such as hipcc, opt, llvm-link, and dcc. This method not only ensures the synchronization of performance data between the device side and the host side, but also significantly improves the efficiency of the performance modeling and optimization process.

[0029] 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.

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

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

[0032] 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 creative work.

[0033] Figure 1 is a flow chart of the present invention; Figure 2 Schematic diagram of lightweight instrumentation counting for edge basic blocks; Figure 3 This is the compilation flow chart of the HIP stub program on the domestic DCU; Figure 4 This is an example of a control flow graph for a HIP program kernel function at the basic block level; Figure 5 A schematic diagram of a computer device provided by an embodiment of the present invention; Figure 6 The present invention is a block diagram of an electronic device provided according to an embodiment.

[0034] Among them, 60. computer equipment; 61. processor; 62. memory; 63. computer program; 600. electronic device; 610. processing unit; 620. storage unit; 6201. random access storage unit; 6202. cache storage unit; 6203. read-only storage unit; 6204. program / utility; 6205. program module; 630. bus; 640. display unit; 650. input / output interface; 660. network adapter; 700. external device. DETAILED DESCRIPTION

[0035] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0036] In the description of the present invention, it should be understood that the terms “include” and “comprises” indicate the presence of 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.

[0037] It should also be understood that the terms used in the present specification are only for the purpose of describing specific 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 plural forms unless the context clearly indicates otherwise.

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

[0039] It should be understood that, although the terms first, second, third, etc. may be used to describe preset ranges, etc. in the embodiments of the present invention, these preset ranges should not be limited to these terms. These terms are only used to distinguish preset ranges from each other. For example, without departing from the scope of the 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.

[0040] 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 determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0041] Various structural schematic diagrams of the embodiments disclosed in the present invention are shown in the accompanying drawings. These figures are not drawn to scale, and some details are magnified and some details may be omitted for the purpose of clear expression. The shapes of various regions and layers shown in the figures and the relative sizes and positional relationships therebetween are only exemplary, and may deviate in practice due to manufacturing tolerances or technical limitations, and those skilled in the art may additionally design regions / layers with different shapes, sizes, and relative positions according to actual needs.

[0042] The present invention provides a control flow graph representation method for obtaining the call relationship of the basic block of the HIP kernel function. First, the kernel function of the HIP program is extracted and compiled into the LLVM IR intermediate code, and the kernel function is divided into multiple basic blocks; a unique serial number is assigned to each basic block, and the call relationship is represented by inserting a new edge basic block on the jump edge; a basic block-level kernel function control flow graph (CFG) is generated; the LLVM plug-in pass is used to plug only the newly added edge basic block to reduce the plug-in range; two lightweight thread plug-in modes are designed to reduce the plug-in overhead, namely ProfileCTA (analyzing a thread block) and ProfileWavefront (analyzing a Wavefront); a compilation process combining device-side and host-side plug-in is adopted, and the method is run on a domestic DCU platform to collect the number of calls between basic blocks, and the dynamic information is used as the edge weight of the CFG, and finally a basic block-level HIP program kernel function CFG with dynamic information is generated. The present invention effectively reduces the plug-in overhead, improves the efficiency of obtaining dynamic call relationships, and provides strong support for high-performance computing and program optimization.

[0043] Example 1 See also Figure 1 The present invention provides a control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function, generates a HIP program kernel function CFG based on the basic blocks with dynamic information on the target platform, so that the control flow graph not only reflects the static structure of the program, but also reflects the actual dynamic behavior of the program during execution. It provides a more accurate basis for subsequent performance modeling and effectively identifies performance bottlenecks and hot spots. Taking the HIP test program running on the domestic DCU platform as an example, it includes the following steps: S1. Obtain the HIP program running on the domestic DCU platform, extract the kernel function of the HIP program, and compile the kernel function into LLVM IR intermediate code through the compiler. The intermediate code divides the kernel function into multiple basic blocks, each of which contains an ordered instruction sequence; The HIP program includes host-side and device-side codes. The device-side kernel function of the HIP program is extracted through the hipcc compiler and converted into hardware-independent LLVM IR intermediate code.

[0044] S2, traverse the 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 to the jump edge between the basic block and its successor, and assign a unique serial number to the newly inserted edge basic block; Insert a new basic block to the jump edge of the basic block and its successor basic block, and combine with step S4 to 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: S201, traverse all basic blocks in the LLVM IR code of the HIP program kernel function, and assign a unique serial number to each basic block, so as to distinguish the original basic block from the subsequent newly added edge basic block; The basic blocks are named Block 1, Block 2 to Block n.

[0045] S202, save the calling relationship between each basic block and all its subsequent basic blocks; The definition of the call relationship is based on the control flow, which refers to the target basic block to which the current basic block will jump after execution. This call relationship is represented by the control flow edges between basic blocks, which can describe the logical execution path of the program. For example, for a basic block containing a conditional branch, it may have multiple successor basic blocks. The call relationship of all successor basic blocks needs to be saved in a structured form to facilitate the subsequent construction of the control flow graph.

[0046] S203, inserting a new basic block to 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, traversing each newly inserted edge basic block, inserting counting function call instructions only into the edge basic block, reducing the insertion scope, so as to obtain the calling relationship and calling times between the basic blocks when the insertion program is subsequently executed.

[0047] The main function of the edge basic block is to represent the control flow jump between the original basic block and the successor basic block. The edge basic block contains specific instructions, such as recording jump information, counting the number of calls, etc., to provide support for subsequent dynamic analysis.

[0048] 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.

[0049] S3. Construct a basic block-level kernel function control flow graph CFG. 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 indicates the direction of the program execution flow. In the control flow graph, each original basic block is a graph node. Each node uses the unique serial number of the basic block as an identifier to distinguish different basic blocks. The node contains 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.

[0050] When adding directed edges, if a basic block has multiple successor basic blocks, add a separate directed edge between each pair of basic blocks to form a complete branch structure representation. If the successor of a basic block contains itself or a predecessor path back to the basic block, a loop will be formed in the control flow graph. When constructing the graph, the loop must be correctly incorporated into the graph structure.

[0051] S4. Through the LLVM instrumentation pass, only the call instruction of the counting function is inserted into the newly added edge basic block to obtain the LLVM IR code after the instrumentation, so that the number of calls of the original basic block to its successor basic block can be output in the subsequent execution; See also Figure 2 , the principle of lightweight instrumentation counting for edge basic blocks Figure 2 , the specific steps are 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 three new parameters, including: basic block list, bank number (to prevent write conflict) and stub granularity; S402, according to the process of step S2, obtaining the LLVM IR code after inserting the edge basic block; S403, traverse all edge basic blocks, and insert a counting function call statement at the beginning of each edge basic block; Among them, the counting function is responsible for tracking the execution of basic blocks, thereby ensuring that the counting operation is triggered at runtime.

[0052] The counting function should include the following four parameters: a counter for storing the counting results of each basic block, the sequence number of the edge basic block, the number of banks, and the granularity of the instrumentation.

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

[0054] S5. Design two lightweight thread instrumentation modes to reduce instrumentation overhead. The first one only analyzes one CTA, which has medium overhead. The second one only analyzes one Wavefront, which has lower overhead. ProfileCTA: Only one thread block CTA is instrumented and analyzed. The thread block at the center of the thread block grid is selected. The thread block at the center can better represent the behavior of most threads, thus achieving a balance between profiling overhead and profiling accuracy. The overhead is medium.

[0055] 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 with minimal overhead.

[0056] The reason why the thread block at the center is selected for analysis is that in some cases, the edge threads of the three-dimensional thread block are only used to load data into the shared memory to assist other threads, but do not participate in the calculation. The behavior of these edge threads may be different from that of most threads, so the thread block at the center of the grid is selected for analysis, which can more accurately represent the behavior of most threads. The same is true for the center Wavefront of the center thread block.

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

[0058] in, Indicates the grid size, which is the number of thread blocks in the three-dimensional directions of x, y, and z. 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 three-dimensional directions of x, y, and z. 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.

[0059] S6. Compile and run the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks to collect the execution times of each edge, and use these execution times as the weights of the edges in CFG, thereby generating a basic block-level HIP program kernel function control flow graph CFG with dynamic information.

[0060] See also Figure 3 , which is the compilation flow chart of the HIP plug-in program on the domestic DCU. On the domestic DCU platform, the overall compilation process of the HIP program to be lightly plugged is as follows: S601, generate the LLVM IR file of the device side through the hipcc compiler for the HIP program running on the domestic DCU platform, generate the instrumented device side IR file through the opt tool, and then link the instrumented device side IR file and the device side runtime file through the llvm-link tool; S602, compiled into a 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 device code must be added to the host LLVM IR file using the -fcuda-include-gpubinary parameter; S604, execute the same process as the device side again to obtain the overall LLVMIR file after the device side and the host side are plugged in, and finally complete the compilation through the compiler dcc and the linker ld to generate an executable file.

[0061] 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, which specifically includes: 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, adding directed edges between the basic block and all its subsequent basic blocks according to the control flow relationship, where the direction of the edge indicates the direction of the program execution flow; S607, running the executable file to collect the count size in each newly added edge basic block, and obtaining 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, so as to generate the final control flow graph of the HIP program kernel function.

[0062] It will be appreciated by those skilled in the art that various aspects of the present invention may be implemented as a system, method or program product. Therefore, various aspects of the present invention may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to herein as a "circuit", "module" or "platform".

[0063] Example 2 The present invention provides a control flow graph representation system for obtaining the calling relationship of the basic blocks of a HIP kernel function. The system can be used to implement the control flow graph representation method for obtaining the calling relationship of the basic blocks of a HIP kernel function. Specifically, the control flow graph representation system for obtaining the calling relationship of the basic blocks of a HIP kernel function includes a partitioning module, a traversal module, a function module, a calling module and an output module.

[0064] Among them, 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 multiple basic blocks, each of which contains an ordered instruction sequence; The traversal module traverses the divided basic blocks, assigns a unique serial number to each basic block, and saves the calling relationship between each basic block and its successor basic block. A new basic block representing the calling relationship is inserted into the jump edge between the basic block and its successor as an edge basic block and is assigned a unique serial number. Function module, builds the kernel function control flow graph at the basic block level. 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 indicates the direction of the program execution flow. The calling module inserts the call instruction of the counting function into the newly added edge basic block through the LLVM instrumentation Pass, obtains the LLVM IR code after instrumentation, and outputs the number of calls of the original basic block to its successor basic block during subsequent execution; Output module, design lightweight thread instrumentation modes, the first one only analyzes one CTA, the second one only analyzes one Wavefront; compile and run the lightweight instrumented LLVM IR intermediate code, get the number of calls between basic blocks, collect the number of executions of each edge, and use the obtained execution number as the weight of the edge in the control flow graph CFG, and generate a basic block-level HIP program kernel function control flow graph CFG with dynamic information.

[0065] Example 3 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 other general-purpose processors, graphics processors (GPU), tensor processors (TPU), digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) 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, and is specifically suitable for loading and executing one or more instructions to implement the corresponding method flow or corresponding function; the processor described in the embodiment of the present invention can be used to obtain the control flow graph representation method of the basic block call relationship of the HIP kernel function, including: 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 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, a directed edge is added between the basic block and all its successor basic blocks. The direction of the edge indicates the direction of the program execution flow. Through the LLVM instrumentation Pass, insert a call instruction to the counting function into the newly added edge basic block to obtain the instrumented LLVM IR code. In 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 IR intermediate code, obtain the number of calls between basic blocks, collect the execution times of each edge, and use the obtained execution times 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.

[0066] See also Figure 5 , the terminal device is a computer device, and 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 on the processor 61. When the computer program 63 is executed by the processor 61, the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function in the embodiment is implemented. To avoid repetition, it is not described one by one here. Alternatively, when the computer program 63 is executed by the processor 61, the control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function in the embodiment is implemented. To avoid repetition, it is not described one by one here.

[0067] The computer device 60 may be a computing device such as a desktop computer, a notebook, a PDA, or a cloud server. The computer device 60 may include, but is not limited to, a processor 61 and a memory 62. Those skilled in the art will appreciate that Figure 5 This is only an example of the computer device 60 and does not constitute a limitation of the computer device 60. It 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.

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

[0069] 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.

[0070] 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 to be output.

[0071] See also Figure 6 The terminal device is an electronic device 600, which is in the form of 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), a display unit 640, etc.

[0072] 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 .

[0073] 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 .

[0074] 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.

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

[0076] The electronic device 600 may also communicate with one or more external devices 700 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 600, and / or communicate with any device that enables the electronic device 600 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output interface 650. Furthermore, the electronic device 600 may also communicate with one or more networks (e.g., local area networks, wide area networks, and / or public networks, such as the Internet) via a network adapter 660. The network adapter 660 may communicate with other modules of the electronic device 600 via a bus 630. It should be understood that, although not shown in the figure, other hardware and / or software modules may 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, etc.

[0077] Example 4 The present invention also provides a storage medium, specifically a computer-readable storage medium, which is a memory device in a terminal device for storing programs and data. It is understandable that the computer-readable storage medium here can include both the built-in storage medium in the terminal device and the extended storage medium supported by the terminal device, and can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it. The computer-readable storage medium provides a storage space, which stores the operating system of the terminal. In addition, one or more instructions suitable for being loaded and executed by a processor are also stored in the storage space, and these instructions can be one or more computer programs (including program codes). It should be noted that more specific examples of the computer-readable storage medium here include: an electrical connection with 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 of the above.

[0078] 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 a program 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.

[0079] 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++, etc., and 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 separate 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 through 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., through the Internet using an Internet service provider).

[0080] The processor may load and execute one or more instructions stored in the 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: 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 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, a directed edge is added between the basic block and all its successor basic blocks. The direction of the edge indicates the direction of the program execution flow. Through the LLVM instrumentation Pass, insert a call instruction to the counting function into the newly added edge basic block to obtain the instrumented LLVM IR code. In 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 IR intermediate code, obtain the number of calls between basic blocks, collect the execution times of each edge, and use the obtained execution times 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.

[0081] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. The components of the embodiments of the present invention described and shown in the drawings here can usually be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

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

[0083] Step 1: Get the HIP program and convert it into LLVM IR Get the HIP program: Get the HIP program on the target domestic DCU platform. The program includes the host-side code and the device-side code.

[0084] Use hipcc compiler: Use hipcc compiler to extract the device-side kernel function of HIP program and convert it into LLVM IR intermediate code to ensure that the intermediate code is independent of hardware architecture for subsequent analysis.

[0085] 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,...).

[0086] Step 2: Generate basic block call relationship Save the calling relationship: traverse all basic blocks and record the calling relationship between each basic block and all its successor basic blocks. The calling relationship is the jump path between the control flows of basic blocks.

[0087] Insert edge basic blocks: For each pair of basic blocks and their successor basic blocks, insert the newly created edge basic blocks. Assign a unique number (Edge1_2) to each newly inserted edge basic block.

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

[0089] Step 3: Build the Control Flow Graph (CFG) 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.

[0090] Add directed edges: According to the recorded basic block call relationship, 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.

[0091] Handle loops and loops: If your program has loops, ensure that loop paths are handled in the graph and correctly reflect the order in which basic blocks are executed.

[0092] Step 4: Instrument LLVM IR Insert count function: Perform lightweight instrumentation on the newly inserted edge basic block, insert the call of count function, and track the number of basic block executions.

[0093] 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.

[0094] Step 5: Lightweight thread instrumentation mode ProfileCTA: Only one thread block (CTA) is instrumented, and the thread block at the center of the grid is selected for analysis. This approach balances overhead and accuracy.

[0095] ProfileWavefront: Analyze only one Wavefront and select the central thread in the Wavefront in the thread block for instrumentation analysis to reduce instrumentation overhead.

[0096] The formula is used to calculate the number of calls between a basic block and its successor basic block using different instrumentation modes (ProfileCTA or ProfileWavefront).

[0097] Step 6: Execute and collect dynamic information Execute instrumented code: Compile and run the instrumented LLVM IR code and collect the execution counts between basic blocks.

[0098] 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.

[0099] Simulation experiment data analysis and result display Visualization of control flow graph: The basic block level control flow graph is displayed through a graphical tool. Each basic block is a node, and the connected directed edges represent the direction of the control flow, and the weight of the edge represents the number of executions.

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

[0101] By dynamically analyzing the HIP program, a control flow graph with dynamic information is constructed, and lightweight instrumentation is used to reduce performance overhead. By analyzing the control flow between each basic block and the subsequent basic block, combined with different instrumentation modes, accurate execution information is obtained, thereby optimizing the execution efficiency of the kernel function.

[0102] In summary, the present invention provides a control flow graph representation method and system for obtaining the calling relationship of the basic blocks of the HIP kernel function, obtains the number of dynamic calls between basic blocks through lightweight instrumentation analysis, and uses it as the edge weight of the control flow graph to generate a basic block-level CFG with dynamic information, accurately reflects the dynamic behavior of the program, provides an accurate basis for performance modeling, and effectively identifies performance bottlenecks and hot spots. The present invention designs two lightweight instrumentation modes (ProfileCTA and ProfileWavefront), and only instruments the newly inserted edge basic blocks at the same time, which significantly reduces the instrumentation overhead. Combined with the instrumentation process of the device side and the host side of the domestic DCU platform, the compilation and instrumentation process are optimized using tools such as hipcc and opt, thereby improving the efficiency of performance data collection. The present invention reduces the graph scale and memory usage through the basic block-level graph representation, improves the graph processing efficiency, is suitable for large-scale parallel computing tasks on supercomputing platforms, and provides efficient support for subsequent program performance modeling and analysis.

[0103] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be 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 in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in 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, which will not be repeated here.

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

[0105] 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. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0106] In the embodiments provided by the present invention, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0107] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0108] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0109] 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, the present invention implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in 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, computer-readable media do not include electric carrier signals and telecommunication signals.

[0110] 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 the 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 generate 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.

[0111] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate 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 A function specified in one or more boxes.

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

[0113] The above contents are 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 a HIP kernel function basic block call relationship, characterized in that: The following steps are involved: S1. 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. S2, 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 into the jump edge between the basic block and its successor as an edge basic block and assign a unique serial number; S3. 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. Directed edges are added between the basic block and all its successor basic blocks according to the control flow relationship. The direction of the edge indicates the direction of the program execution flow. 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 of the original basic block to its successor basic block during subsequent execution. S5. Design lightweight thread instrumentation modes. The first one only analyzes one CTA, and the second one only analyzes one Wavefront. S6. Compile and run the lightweight instrumented LLVM IR intermediate code to obtain the number of calls between basic blocks, collect the number of executions of each edge, and use the obtained number of executions 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.

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, and assign a unique serial number to each basic block, so as to distinguish the original basic block from the subsequent newly added edge basic block; S202, save the calling relationship between each basic block and all its subsequent basic blocks; S203, inserting a new basic block to 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 block, and obtain the calling relationship and calling times between the basic blocks when the stub 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: In the control flow graph of step S3, each original basic block is used 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.

5. 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 stub granularity; S402, obtaining 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 the instrumented LLVM IR code to implement lightweight instrumentation counting for edge basic blocks.

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

7. 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: In step S5, the lightweight thread instrumentation mode includes: ProfileCTA: Only one thread block CTA is instrumented, and the thread block at the center of the thread block grid is selected; ProfileWavefront: Analyze a Wavefront and select all threads in the center Wavefront of the center thread block for instrumentation analysis.

8. The control flow graph representation method for obtaining the calling relationship of the basic blocks of the HIP kernel function according to claim 7 is characterized in that: The number of times a basic block calls 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.

9. 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 LLVM IR file of the device side through the hipcc compiler for the HIP program running on the domestic DCU platform, generate the instrumented device side IR file through the opt tool, and then link the instrumented device side IR file and the device side runtime file through the llvm-link tool; S602, compiled into a 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 device code must be added to the host LLVM IR file using the -fcuda-include-gpubinary parameter; S604, executing the same process as the device side again, obtaining the overall LLVM IR file after the device side and the host side are plugged in, completing 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, adding directed edges between the basic block and all its subsequent basic blocks according to the control flow relationship, where the direction of the edge indicates the direction of the program execution flow; S607, running the executable file to collect the count size in each newly added edge basic block, and obtaining 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, and generate the final HIP program kernel function control flow graph.

10. 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; The traversal module traverses the divided basic blocks, assigns a unique serial number to each basic block, and saves the calling relationship between each basic block and its successor basic block. A new basic block representing the calling relationship is inserted into the jump edge between the basic block and its successor as an edge basic block and is assigned a unique serial number. Function module, builds the kernel function control flow graph at the basic block level. 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 indicates the direction of the program execution flow. The calling module inserts the call instruction of the counting function into the newly added edge basic block through the LLVM instrumentation Pass, obtains the LLVM IR code after instrumentation, and outputs the number of calls of the original basic block to its successor basic block during subsequent execution; The output module designs 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 IR intermediate code to obtain the number of calls between basic blocks, collect the number of executions of each edge, and use the obtained number of executions 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.

Images