Code coverage rate statistics method and related product thereof

Abstract

The invention relates to a code coverage rate counting method and a related product thereof. The related product comprises code coverage rate counting equipment and a computer readable storage medium. The apparatus may be included in a computing processing device of a combined processing device, which may include one or more data processing devices. The combined processing device can also comprise an interface device and other processing devices. And the computing processing device interacts with other processing devices to jointly complete computing operation specified by a user. The combined processing device can further comprise a storage device, and the storage device is connected with the equipment and the other processing devices and used for storing data of the equipment and the other processing devices. According to the scheme of the invention, the support of the heterogeneous programming code coverage rate statistics is realized, and the improvement of the code robustness and the improvement of the readability of the heterogeneous programming code are facilitated.

Description

Technical Field

[0001] This disclosure generally relates to the field of computers. More specifically, this disclosure relates to a method, apparatus, computer-readable storage medium, and heterogeneous computing system for code coverage collection. Background Technology

[0002] With the rapid development of artificial intelligence and deep learning, neural network processing units (NPUs) such as GPUs have been widely used. Obtaining code coverage information is crucial for optimizing and debugging programs running on NPUs. Code coverage is a white-box testing method that assesses the completeness and code quality of tests by statistically analyzing the proportion of code actually executed during testing relative to the total code.

[0003] Existing NPU code coverage solutions typically include several stages: compile-time instrumentation, runtime data collection, and post-processing report generation. Taking a GPU solution as an example, during compilation, code and data are inserted into each compilation unit to statistically analyze execution frequency and generate a mapping between source code and coverage data for post-processing. At runtime, the instrumented code records the execution status of basic blocks, and after the kernel execution is complete, the coverage data is copied from the device side back to the host. The post-processing stage uses specialized tools to parse binary files and coverage data, and generate an HTML report.

[0004] However, existing NPU code coverage solutions have shortcomings in scenarios involving joint compilation by multiple compilation units. First, the initialization and unregistration code of each compilation unit is independent, making it impossible to correctly initialize, merge, and collect coverage data from all compilation units during actual execution. Second, the linking process on the device side does not consider merging coverage-related data from different compilation units, resulting in incomplete coverage data obtained during post-processing. Finally, post-processing tools cannot correctly parse the binary file after linking multiple files, thus failing to extract complete source code mapping relationships and merged coverage data.

[0005] In summary, existing NPU code coverage schemes are difficult to apply directly to scenarios involving joint compilation of multiple compilation units. Therefore, how to implement an NPU code coverage scheme that supports multiple compilation units and multiple file linking to obtain complete and accurate coverage data is a technical challenge that needs to be solved. Summary of the Invention

[0006] In view of the technical problems mentioned in the background section above, this disclosure proposes a scheme for code coverage collection. Using the technical solution of this disclosure, coverage collection of heterogeneous programming code in scenarios with multiple compilation units and multiple file linking can be effectively supported.

[0007] In a first aspect, this disclosure provides a method for code coverage collection, comprising: during code compilation, initializing and unregistering each compilation unit using a list of function pointers to generate initial code coverage data; and during device-side linking, using a linker to concatenate coverage-related segments to merge code coverage data updated by multiple compilation units after code execution.

[0008] In a second aspect, this disclosure provides an apparatus for code coverage collection, comprising: one or more processors; and a memory storing computer instructions for code coverage collection in a heterogeneous neural network processing unit (NPU) environment, wherein when the computer-executable instructions are executed by the one or more processors, the apparatus causes the apparatus to perform the method described in the first aspect.

[0009] In a third aspect, this disclosure provides a computer-readable storage medium storing computer instructions for code coverage collection, which, when executed by one or more processors, perform the method described in the first aspect.

[0010] In a fourth aspect, this disclosure provides a heterogeneous computing system including a host side and a device side, wherein the device side performs the method as described in the first aspect.

[0011] The solutions provided in the above-mentioned aspects of this disclosure effectively support coverage statistics for heterogeneous programming code. Specifically, during code compilation, initialization and unregistration operations are performed on each compilation unit using a function pointer list, generating initial code coverage data and providing a foundation for subsequent coverage data updates after code execution. Simultaneously, during device-side linking, the linker can concatenate coverage-related segments, thereby merging coverage data from different compilation units and ensuring the integrity of the coverage data. This solution eliminates the need to generate additional coverage information files for each compilation unit, saving file I / O overhead and simplifying the processing logic of the device-side assembler.

[0012] Furthermore, the function pointer list used in this disclosure includes an initialization function pointer list and a deregistration function pointer list, which respectively record the initialization and deregistration functions of each compilation unit, ensuring that code coverage data from different compilation units can be correctly initialized and collected. In addition, by organizing coverage-related data into segments and merging them by the linker, this scheme can well adapt to scenarios with multiple compilation units.

[0013] Furthermore, during linker relocation, the segment length can be obtained by calculating the difference between the start and end addresses of coverage-related segments, facilitating the reading of coverage data. Additionally, an extended code coverage analysis tool is used to parse the linked binary file, starting the parsing from the merged coverage data based on the coverage data offset, and generating a complete code coverage report accordingly. This achieves comprehensive support for coverage data collection and presentation in multi-file linking scenarios. Attached Figure Description

[0014] The above and other objects, features, and advantages of exemplary embodiments of the present disclosure will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the present disclosure are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0015] Figure 1 This is a structural diagram of a board according to an embodiment of the present disclosure;

[0016] Figure 2 This is a structural diagram illustrating a combined processing apparatus according to an embodiment of the present disclosure;

[0017] Figure 3 This is a schematic diagram showing the internal structure of a computing device according to an embodiment of the present disclosure;

[0018] Figure 4 This is a schematic diagram illustrating the internal structure of a processor core according to an embodiment of the present disclosure;

[0019] Figure 5 This is a schematic diagram illustrating the data writing process between processor cores of different clusters according to embodiments of the present disclosure;

[0020] Figure 6 This is a schematic diagram illustrating the hardware and software architecture of dataflow programming according to embodiments of the present disclosure;

[0021] Figure 7 This is a simplified flowchart illustrating a method for performing coverage statistics on heterogeneous programming code according to an embodiment of the present disclosure;

[0022] Figure 8 This schematically illustrates a flowchart of compiling and instrumenting source code according to embodiments of the present disclosure;

[0023] Figure 9 This schematically illustrates a flowchart of collecting coverage data during device-side operation according to an embodiment of the present disclosure;

[0024] Figure 10 This schematically illustrates a flowchart of merging coverage-related segments during the device-side linking phase according to an embodiment of the present disclosure;

[0025] Figure 11 This schematically illustrates a flowchart of code execution after instrumentation according to embodiments of the present disclosure; and

[0026] Figure 12 The flowchart illustrating the parsing and generation of a coverage report during the post-processing stage according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0027] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] It should be understood that the terms "first," "second," "third," and "fourth," etc., in the claims, specification, and drawings of this disclosure are used to distinguish different objects, rather than to describe a specific order. The terms "comprising" and "including" as used in the specification and claims of this disclosure indicate the presence of the described features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof.

[0029] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure. As used in this disclosure and claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this disclosure and claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations.

[0030] As used in this specification and claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0031] As mentioned above, the solution disclosed herein can be applied to heterogeneous computer systems, such as heterogeneous computing platforms composed of host-side (e.g., CPUs) and device-side (e.g., AI chips, GPUs), where the host-side and device-side hardware processors can have different instruction set architectures. In the application scenario of this disclosure, the heterogeneous computing platform can support heterogeneous programming code. For example, the heterogeneous programming code can include host-side code and device-side code, where the host-side code can run on the host side and the device-side code can run on the device side. During the actual execution of the heterogeneous programming code, the device-side code and its required data are first copied from the host side to the device side (e.g., through a driver). The device side executes the device-side code to obtain the corresponding execution result, and finally, the execution result is copied from the device side to the host side.

[0032] Therefore, heterogeneous programming code is relatively complex, and it is not easy for relevant personnel to understand the logic of heterogeneous programming code, thus making it impossible to ensure the robustness of the code. In order to overcome the shortcomings of the prior art discussed here and in the background section, the present disclosure proposes a solution that can generate a unified coverage report on heterogeneous programming code, thereby enabling support for heterogeneous programming code coverage statistics and helping to improve code robustness and facilitate the interpretation and optimization of heterogeneous programming code by relevant personnel.

[0033] The device side in this embodiment may be an artificial intelligence chip or board, etc. Figure 1 A schematic diagram of the structure of a board 100 according to an embodiment of this disclosure is shown. Figure 1 As shown, the board 100 includes a chip (or "processing chip") 101, which is a system-on-a-chip (SoC) that integrates one or more combined processing devices. These combined processing devices are artificial intelligence computing units used to support various deep learning and machine learning algorithms, meeting the intelligent processing needs of complex scenarios in fields such as computer vision, speech, natural language processing, and data mining. In particular, deep learning technology is widely used in cloud intelligence. A significant characteristic of cloud intelligence applications is the large volume of input data, placing high demands on the platform's storage and computing capabilities. The board 100 in this embodiment is suitable for cloud intelligence applications, possessing massive off-chip storage, on-chip storage, and substantial computing power.

[0034] Chip 101 is connected to external device 103 via external interface device 102. External device 103 may be, for example, a server, computer, camera, monitor, mouse, keyboard, network card, or Wi-Fi interface. Data to be processed can be transmitted from external device 103 to chip 101 via external interface device 102. The calculation results from chip 101 can be transmitted back to external device 103 via external interface device 102. Depending on the application scenario, external interface device 102 may have different interface forms, such as a PCIe interface.

[0035] The board 100 also includes a storage device 104 for storing data, which includes one or more memory cells 105. The storage device 104 is connected to and transmits data with the controller 107 and the chip 101 via a bus. The controller 106 in the board 100 is configured to regulate the state of the chip 101. For this purpose, in one application scenario, the controller 106 may include a microcontroller (MCU).

[0036] Figure 2 This is a structural diagram illustrating the combined processing device 200 in chip 101 of this embodiment. (As shown...) Figure 2 As shown, the combined processing device 200 includes a computing device 201, an interface device 202, a processing device 203, and a DRAM 204.

[0037] The computing device 201 is configured to perform user-specified operations. It is mainly implemented as a single-core intelligent processor or a multi-core intelligent processor to perform deep learning or machine learning calculations. It can interact with the processing device 203 through the interface device 202 to jointly complete the user-specified operations.

[0038] Interface device 202 is used to transmit data and control commands between computing device 201 and processing device 203. For example, computing device 201 can obtain input data from processing device 203 via interface device 202 and write it to on-chip storage device of computing device 201. Further, computing device 201 can obtain control commands from processing device 203 via interface device 202 and write them to on-chip control cache of computing device 201. Alternatively or optionally, interface device 202 can also read data from storage device of computing device 201 and transmit it to processing device 203.

[0039] Processing device 203, as a general-purpose processing device, performs basic control including but not limited to data transfer, and starting and / or stopping computing device 201. Depending on the implementation, processing device 203 may be one or more types of processors, including but not limited to digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., and their number can be determined according to actual needs. As mentioned above, computing device 201 disclosed herein can be considered as having a single-core structure or a homogeneous multi-core structure. However, when computing device 201 and processing device 203 are considered together, they are considered to form a heterogeneous multi-core structure.

[0040] DRAM 204 is used to store data to be processed. It is DDR memory, typically 16G or larger in size, and is used to store data in computing device 201 and / or processing device 203.

[0041] Figure 3 A schematic diagram of the internal structure of computing device 201 is shown. Computing device 201 is used to process input data such as computer vision, speech, natural language processing, and data mining. The computing device 201 in the diagram adopts a multi-core hierarchical architecture design. As a system-on-a-chip, computing device 201 includes multiple clusters, each of which includes multiple processor cores, which can be used to execute the tasks disclosed herein. In other words, computing device 201 is constructed in a hierarchical structure of system-on-a-chip, clusters, and processor cores.

[0042] From the perspective of system-on-a-chip hierarchy, such as Figure 3 As shown, the computing device 201 includes an external storage controller 301, a peripheral communication module 302, an on-chip interconnect module 303, a synchronization module 304, and multiple clusters 305.

[0043] There can be multiple external storage controllers 301; two are shown as an example in the figure. These controllers are used to access external storage devices, such as those issued by the processor core, in response to access requests from the processor core. Figure 2The DRAM 204 in the chip allows the computing device 201 to read data from external sources or write data to external sources. The peripheral communication module 302 receives control signals from the processing device 203 via the interface device 202, initiating the computing device 201 to execute tasks. The on-chip interconnect module 303 connects the external storage controller 301, the peripheral communication module 302, and multiple clusters 305 to transmit data and control signals between the modules. The synchronization module 304 is a Global Barrier Controller (GBC) used to coordinate the working progress of each cluster and ensure information synchronization. The multiple clusters 305 are the computing core of the computing device 201. Four are shown exemplarily in the figure; however, with hardware development, the computing device 201 disclosed herein may also include 8, 16, 64, or even more clusters 305.

[0044] From the perspective of cluster hierarchy, such as Figure 3 As shown, each cluster 305 includes multiple processor cores (IPU cores) 306 and one memory core (MEM core) 307.

[0045] Four processor cores 306 are shown in the figure as an example; this disclosure does not limit the number of processor cores 306. Its internal architecture is as follows: Figure 3 As shown. Each processor core 306 includes three main modules: a control module 31, an arithmetic module 32, and a storage module 33.

[0046] The control module 31 coordinates and controls the operation of the computation module 32 and the storage module 33 to complete the deep learning task. It includes an instruction fetch unit (IFU) 411 and an instruction decode unit (IDU) 412. The instruction fetch unit 411 fetches instructions from the processing device 203, and the instruction decode unit 412 decodes the fetched instructions and sends the decoding result as control information to the computation module 32 and the storage module 33.

[0047] The computation module 32 includes a vector operation unit 421 and a matrix operation unit 422. The vector operation unit 421 is used to perform vector operations and can support complex operations such as vector multiplication, addition, and nonlinear transformations; the matrix operation unit 422 is responsible for the core computations of deep learning algorithms, namely matrix multiplication and convolution.

[0048] Storage module 33 is used to store or move related data, including Neuron RAM (NRAM) 431, Weight RAM (WRAM) 432, Input / Output Direct Memory Access (IODMA) 433, and Move Direct Memory Access (MVDMA) 434. NRAM 431 is used to store input, output data, and intermediate results for computation by processor core 306; WRAM 432 is used to store the weights of the deep learning network; IODMA 433 controls the memory access of NRAM 431 / WRAM 432 and DRAM 204 through broadcast bus 309; MVDMA 434 controls the memory access of NRAM 431 / WRAM 432 and SRAM 308.

[0049] Back Figure 3 The storage core 307 is primarily used for storage and communication, namely storing shared data or intermediate results among processor cores 306, and performing communication between cluster 305 and DRAM 204, communication between clusters 305, and communication between processor cores 306. In other embodiments, the storage core 307 has scalar operation capabilities and is used to perform scalar operations.

[0050] Storage core 307 includes a shared memory unit (SRAM) 308, a broadcast bus 309, a Cluster Direct Memory Access (CDMA) module 310, and a Global Direct Memory Access (GDMA) module 311. SRAM 308 acts as a high-performance data relay station. Data multiplexed between different processor cores 306 within the same cluster 305 does not need to be obtained from DRAM 204 by each processor core 306 individually. Instead, it is relayed between processor cores 306 via SRAM 308. Storage core 307 only needs to quickly distribute the multiplexed data from SRAM 308 to multiple processor cores 306, thereby improving inter-core communication efficiency and significantly reducing on-chip and off-chip I / O access.

[0051] Broadcast bus 309, CDMA 310, and GDMA 311 are used to perform communication between processor cores 306, communication between clusters 305, and data transfer between cluster 305 and DRAM 204, respectively. These will be explained below.

[0052] The broadcast bus 309 is used to complete high-speed communication between the processor cores 306 within the cluster 305. In this embodiment, the broadcast bus 309 supports inter-core communication methods including unicast, multicast, and broadcast. Unicast refers to point-to-point (i.e., data transmission from one processor core to another) data transmission. Multicast is a communication method that transmits a piece of data from SRAM 308 to several specific processor cores 306. Broadcast is a communication method that transmits a piece of data from SRAM 308 to all processor cores 306, and is a special case of multicast.

[0053] CDMA 310 is used to control SRAM 308 access between different clusters 305 within the same computing device 201. Figure 11 This diagram illustrates the operation of CDMA310 when one processor core attempts to write data to another processor core in a different cluster. In this application scenario, the same computing device comprises multiple clusters. For simplicity, only clusters 0 and 1 are shown in the diagram. Both clusters 0 and 1 contain multiple processor cores; similarly, for ease of explanation, only processor core 0 is shown in cluster 0, and only processor core 1 is shown in cluster 1. Processor core 0 intends to write data to processor core 1.

[0054] First, processor core 0 sends a unicast write request to write data into its local SRAM 0. CDMA 0 acts as the master and CDMA 1 acts as the slave. The master pushes the write request to the slave, that is, the master sends the write address AW and the write data W to transmit the data to SRAM 1 of cluster 1. Then, the slave sends a write response B as a response. Finally, processor core 1 of cluster 1 sends a unicast read request to read the data from SRAM 1.

[0055] Back Figure 3The GDMA 311, in conjunction with the external memory controller 301, controls memory access from the SRAM 308 to the DRAM 204 of the cluster 305, or reads data from the DRAM 204 into the SRAM 308. As described above, communication between the DRAM 204 and the NRAM 431 or WRAM 432 can be achieved through two channels. The first channel is a direct connection between the DRAM 204 and the NRAM 431 or WRAM 432 via the IODAM 433; the second channel involves first transmitting data between the DRAM 804 and SRAM 308 via the GDMA 311, and then transmitting data between the SRAM 308 and the NRAM 431 or WRAM 432 via the MVDMA 434. Although the second channel appears to require more components and has a longer data flow, in some embodiments, the bandwidth of the second channel is actually much greater than that of the first channel. Therefore, communication between the DRAM 204 and the NRAM 431 or WRAM 432 may be more efficient via the second channel. The embodiments of this disclosure can select the data transmission channel according to their own hardware conditions.

[0056] In other embodiments, the functions of GDMA 311 and IODMA 433 can be integrated into the same component. For ease of description, this disclosure treats GDMA 311 and IODMA 433 as different components. For those skilled in the art, any component whose implemented functions and achieved technical effects are similar to this disclosure is within the scope of protection of this disclosure. Furthermore, the functions of GDMA 311, IODMA 433, CDMA 310, and MVDMA 434 can also be implemented by the same component. Similarly, any component whose implemented functions and achieved technical effects are similar to this disclosure is within the scope of protection of this disclosure.

[0057] The above combination Figures 1-5 The hardware architecture and internal structure of this disclosure are described in detail. It is understood that the above description is merely exemplary and not restrictive. Depending on different application scenarios and hardware specifications, those skilled in the art can also make changes to the board (or artificial intelligence device) and its internal structure disclosed herein, and such changes still fall within the protection scope of this disclosure. In addition to... Figures 1-5 The hardware architecture shown in this disclosure also involves software and hardware architecture, which will be described below.

[0058] Figure 6The diagram illustrates a hardware and software architecture design according to an embodiment of this disclosure. As shown in the diagram, the hardware and software architecture in this embodiment may include an AI processor 601, a driver and operating system 602, a compiler and programming language 603, a library 604, a framework layer 605, and an application layer 606. It is understood that this hardware and software architecture can be applied to the artificial intelligence computing system or heterogeneous computing platform of this application.

[0059] Specifically, the AI ​​processor 601 (which may, for example, be included in the board described below in conjunction with the accompanying drawings) incorporates both computational and data handling optimizations in its hardware design. To this end, it employs customized computational units to accelerate computation and uses on-chip memory to accelerate data handling, thereby achieving extremely high performance and energy efficiency. Furthermore, to support various algorithm optimizations, the AI ​​processor 601 can have customized computational units and instruction sets, where the instruction set can provide computational instructions of different granularities (scalar, vector, and / or matrix). Moreover, considering factors such as algorithm memory access characteristics, hardware cost, and verification difficulty, on-chip memory can be used, and data handling can be optimized. In practical operation, the AI ​​processor of this disclosure can achieve speeds exceeding those of mainstream GPUs (Graphics Processing Units) by tens of times.

[0060] The driver and operating system 602 are primarily responsible for scheduling tasks on the AI ​​processor 601. This scheduling operation can, for example, perform scheduling based on task priority, communication and synchronization between multiple devices. For the compiled program, the operating system and driver can schedule and execute the tasks to be performed on a specific processor, including but not limited to the following operations: allocating and releasing device memory, enabling data transfer between devices, maintaining task queues, and scheduling tasks according to priority to achieve synchronization and cooperation between multiple devices.

[0061] The compiler and programming language 603 can be an assembly language developed for the instruction set of the AI ​​processor 601. In applications, it can translate deep learning operators developed for the AI ​​processor 601 into combinations of processor instructions, enabling the AI ​​processor 601 to be invoked efficiently. In some application scenarios, the compiler can be used to optimize the compilation process by executing intermediate expression stages.

[0062] Library 604 may include runtime library 614 and machine learning library 624. In one implementation scenario, the aforementioned library 604 can use the instruction set of AI processor 601 and perform partial optimizations based on the instruction set of AI processor 601 to improve the running speed of operators. Runtime library 614 may be a high-performance operator library specifically developed for AI processor 601, and it can be used to complete the interaction between general-purpose processors and artificial intelligence processors. Furthermore, runtime library 614 can also provide a set of interfaces for artificial intelligence processors. As for machine learning library 624, it can be used to accelerate various machine learning or deep learning algorithms on artificial intelligence processors. Specifically, machine learning library 624 can provide a set of efficient, general-purpose, flexible and scalable programming interfaces. Its upper-layer machine learning applications can directly adopt the programming interfaces of various programming frameworks (such as PyTorch, TensorFlow, Caffe, MXNet, etc.), or can directly program using the interface provided by machine learning library 624. In addition, the machine learning library 624 disclosed herein can be easily called by hardware platforms, while runtime library 614 can implement some basic and commonly used operators, such as convolution, pooling and other operations.

[0063] Framework layer 605 can add encapsulation for operators developed for AI processors, primarily encapsulating operators from runtime library 614. In addition, framework layer 605 can modify related task scheduling or memory management components. In one application scenario, framework layer 605 can adopt the architecture of frameworks such as TensorFlow.

[0064] The specific embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0065] Figure 7 This is a flowchart illustrating a method 700 for code coverage collection according to an embodiment of the present disclosure. The method 700 can be applied to heterogeneous computer systems to achieve complete collection of code coverage data in scenarios with multiple compilation units and multiple file linking.

[0066] like Figure 7As shown, in step S702, during code compilation, initialization and unregistration operations are performed on each compilation unit using a function pointer list to generate initial code coverage data. In one embodiment, the aforementioned function pointer list includes an initialization function pointer list for recording the initialization functions of each compilation unit and an unregistration function pointer list for recording the unregistration functions of each compilation unit. Each item in the initialization function pointer list corresponds to an initialization function of a compilation unit, and each item in the unregistration function pointer list corresponds to an unregistration function of a compilation unit. During the initialization operation, memory can be allocated for the coverage data and numerical initialization can be performed. During the unregistration operation, coverage data collection and related resource cleanup can be performed. Furthermore, in some embodiments, the coverage data of each compilation unit can be organized in a segment-based manner to facilitate subsequent linker merging operations.

[0067] Next, in step S704, during device-side linking, the linker performs a concatenation operation on coverage-related segments to merge code coverage data updated by multiple compilation units after code execution. These coverage-related segments may include, but are not limited to, function coverage information segments, code coverage mapping segments, and function name segments.

[0068] The method 700 and its various embodiments disclosed herein can effectively support code coverage data collection in scenarios with multiple compilation units and multiple file linking. By introducing a function pointer list during compilation, the problem of missing coverage data caused by the independent initialization and unregistration operations of different compilation units can be solved. Furthermore, the linker's merging operation of coverage-related sections ensures that the final generated binary file contains complete coverage data for all compilation units. Therefore, method 700 solves the problem of incomplete coverage data caused by the lack of effective handling of multi-file linking scenarios in the prior art.

[0069] Figure 8The diagram illustrates a flowchart of a compile-time execution method 800 according to an embodiment of the present disclosure. This method 800 can be executed by a compiler, which can compile and instrument the source code; this step is the starting point of the code coverage collection method. In the device-side runtime environment, this step can consider the device-side instruction set and memory model to ensure that the generated compilation unit can be correctly executed on the device side. Specifically, at step S804, the compiler generates coverage-related auxiliary functions and data structures for each compilation unit. In this disclosure, a compilation unit is a broader concept that can represent a unit of code processed by the compiler; it can correspond to various types of source code files, including but not limited to files such as ".c", ".cpp", ".cu", or ".mlu". The compilation unit can represent various types of source files. During this compilation process, the compiler performs code instrumentation, that is, inserts instructions for collecting coverage data (including but not limited to instructions for initializing coverage data, instructions for statistically analyzing coverage data, and instructions for clearing coverage data) at appropriate locations.

[0070] As an example, as shown in the figure, step S804 may include: generating an initialization function for the compilation unit at step S804-1. This initialization function is responsible for allocating memory for the coverage data and performing numerical initialization. When considering a multi-core architecture on the device side, this initialization process can be performed synchronously on each core. At step S804-2, the initialization function pointer is added to the initialization function pointer list. As an example, this list can be a global data structure used to quickly locate and call the initialization function of each compilation unit at runtime.

[0071] Next, the process generates a deregistration function for this compilation unit at step S804-3. The main task of the deregistration function is to collect coverage data and clean up related resources when the program execution ends. Specifically, it aggregates the coverage data collected during runtime from the local memory of each kernel (such as the aforementioned "LDRAM") to global memory (such as the aforementioned "GDRAM"), and then releases the memory resources allocated for coverage collection. Subsequently, at step S804-4, the deregistration function pointer is added to the deregistration function pointer list. This list is similar to the initialization function pointer list and is used to call the deregistration function of each compilation unit in an orderly manner when the program ends.

[0072] The process then proceeds to step S806. In step S806, coverage data is organized in a segment-based manner within the compilation unit. In this disclosure, a "section" refers to a data block in an object file that has specific attributes and uses. Using a segment-based approach allows for the separate storage of different types of coverage data, facilitating subsequent linking and processing. As an example, this step may include: at step S806-1, a function coverage information segment (as described later, "__llvm_covfun") can be generated to store the hash values ​​and coverage counters of each function; at step S806-2, a code coverage mapping segment (as described later, "__llvm_covmap") can be generated to establish a mapping relationship between source code and coverage data for subsequent generation of a readable coverage report; at step S806-3, a function name segment (as described later, "__llvm_prf_names") can be generated to store relevant function name information, facilitating the display of specific function names in the coverage report.

[0073] Through these steps, the compile-time processing not only completes the code compilation but also prepares the necessary coverage collection functions and data structures for each compilation unit. This design considers device-side hardware characteristics, such as multi-core architecture and special memory hierarchies, ensuring that coverage data can be efficiently collected and managed on the device side. Simultaneously, the segment-based organization facilitates subsequent multi-file linking operations, enabling accurate collection and merging of coverage information even in complex heterogeneous environments.

[0074] Figure 9 A flowchart of a method 900 executed at runtime according to an embodiment of the present disclosure is shown. This method 900 is executed in a heterogeneous neural network processing unit (NPU) environment and is suitable for multi-file linking scenarios. Figure 9 As shown, in step S902, the instrumented code is loaded and executed on the device side. This step marks the beginning of coverage data collection, loading the compiled and linked code onto the device side.

[0075] Next, the process proceeds to step S904. In step S904, functions from the list of initialization function pointers generated during compilation are called to perform initialization operations on each compilation unit. This step ensures that the coverage collection environment for each compilation unit is correctly set up. Specifically, this step may include: in step S904-1, allocating memory for the coverage data of this compilation unit. Considering the memory architecture, this memory allocation needs to be performed in GDRAM (Global DRAM) to ensure that all cores can access the coverage data. In step S904-2, initial values ​​are set for the coverage data of this compilation unit. This includes initializing all coverage counters to 0 to prepare for subsequent data collection.

[0076] The process then proceeds to step S906. In step S906, device-side code is executed, and coverage data is collected. Specifically, this step may include: in step S906-1, executing the instrumented code and statistically analyzing the execution status of the code path. The instrumented code updates the corresponding counters when each basic block is executed. In a multi-core environment, this process needs to consider the parallel execution of multiple cores to ensure that the counter updates are atomic and avoid data races. In step S906-2, the coverage data of the corresponding compilation unit is updated based on the execution status. Due to the multi-core characteristics of multi-core heterogeneous systems, this update operation needs to be performed in the local storage of each core (such as "LDRAM") to reduce access to global memory and improve performance.

[0077] Next, the process proceeds to step S908. After the device-side code execution is complete, functions from the list of unregistered function pointers generated during compilation are called to perform unregistered operations for each compilation unit. This step ensures that coverage data is correctly collected and cleaned up. Specifically, this step may include: at step S908-1, collecting coverage data for the compilation unit. This process requires aggregating coverage data from various kernel local storages into global memory (such as GDRAM), involving data synchronization and merging operations. At step S908-2, cleaning up coverage-related resources for the compilation unit. This step may include releasing memory allocated for coverage collection and resetting related data structures.

[0078] Finally, in step S910, the updated coverage data for all compilation units is transmitted from the device side to the host side. This step involves data transmission between the device and the host, and the efficiency and correctness of the data transmission need to be considered. The transmitted data includes function coverage information (__llvm_covfun), code coverage mapping (__llvm_covmap), and function name information (__llvm_prf_names), etc.

[0079] Through these steps, runtime processing enables the collection and management of coverage data for multi-file linked programs on the device side. This method fully considers multi-core architectures and memory hierarchies, ensuring efficient and accurate collection of coverage data.

[0080] Figure 10 A flowchart of a method 1000 executed during the device-side linking phase according to an embodiment of this disclosure is shown. This method 1000 can be executed by a linker in a heterogeneous neural network processing unit (NPU) environment, and is particularly suitable for multi-file linking scenarios on a device-side platform. This method 1000 is used to merge coverage data updated by all compilation units, and can be executed before the aforementioned step S910.

[0081] like Figure 10 As shown, in step S1002, the linker reads all compilation units and their runtime coverage data. This step is the starting point for multi-file linking; the linker reads all compilation units generated during compilation, including their code segments, data segments, and coverage-related special segments.

[0082] Next, the process proceeds to step S1004. In step S1004, the linker merges coverage-related segments. This step is crucial for coverage collection under multi-file linking. Specifically, step S1004 may include: In step S1004-1, merging function coverage information segments (e.g., "__llvm_covfun") from all compilation units. During this process, the linker needs to ensure that coverage information for the same functions in different compilation units is correctly merged, avoiding duplication or omission. In step S1004-2, merging code coverage mapping segments (e.g., "__llvm_covmap") from all compilation units. This merging process needs to maintain the correct mapping between source code and coverage data, especially in the case of cross-file function calls. Next, in step S1004-3, merging function name segments (e.g., "__llvm_prf_names" as described later) from all compilation units. This step ensures that the names of all functions are correctly displayed in the final coverage report, including those defined in different files.

[0083] The process then proceeds to step S1006. In step S1006, the linker assigns values ​​to the start and end (_start / _end) addresses of the coverage-related segments during the relocation phase. Specifically, step S1006 may include: in step S1006-1, assigning values ​​to the "__start" and "__end" symbols of the merged function coverage information segment (e.g., "__llvm_covfun"). In step S1006-2, assigning values ​​to the "__start" and "__end" symbols of the merged code coverage map segment (e.g., "__llvm_covmap"). Similarly, in step S1006-3, assigning values ​​to the "__start" and "__end" symbols of the merged function name segment (e.g., "__llvm_prf_names").

[0084] Finally, in step S1008, the linker generates the final executable file. This executable file contains not only the merged code and data, but also complete coverage collection-related segments and information. Specifically, the linker generates a symbol such as "fatbinData" in the executable file, whose value points to the offset corresponding to the merged "fatbin" in the ".cn_fatbin" segment (details will be described later). This information is used for subsequent coverage data parsing, especially in the case of multi-file linking. Additionally, it should be noted that the actual length of the coverage-related segments is calculated by performing a subtraction operation between the start and end addresses on the device side.

[0085] Through these steps, the device-side linking process enables the correct merging and management of coverage-related information from multiple compilation units. This design is particularly well-suited to the characteristics of device-side platforms, such as multi-core architectures and unique memory models, ensuring that coverage data can be correctly collected, merged, and accessed in complex heterogeneous environments and multi-file linking scenarios.

[0086] As can be seen, this disclosure proposes a method for device-side coverage collection in multi-file linking scenarios. This method redesigns the entire compiler instrumentation scheme to address the problem of incomplete coverage data collection in existing technologies under multi-file linking conditions. Figure 11 An execution flow diagram after user code instrumentation according to an embodiment of the present disclosure is shown.

[0087] like Figure 11As shown, this disclosure uses a list of function pointers for initialization and unregistration operations, which differs from the traditional method of directly generating the initialization code for the current compilation unit in __llvm_profile_init and __llvm_profile_finalize. Specifically, __prof_ctors and __prof_dtors correspond to the function pointer lists for initialization and unregistration operations, respectively, and internally store the function pointers of the initialization and unregistration functions for each compilation unit.

[0088] In the `__llvm_profile_register_functions` function, the system iterates through each entry in `__prof_ctors`, which corresponds to the initialization function (corresponding to `__llvm_profile_init_${module_id}`) of each compilation unit involved in the linking process, and calls these function pointers to perform the initialization operations respectively. This design enables independent initialization of each compilation unit in the case of multi-file linking, thereby ensuring the integrity of coverage data.

[0089] It is worth noting that when copying __llvm_prf_nm and traversing __prof_ctors and __prof_dtors, the length of the target array is not a static constant, but depends on the length of the target section after linking on the device side.

[0090] For example, to obtain the length of __prof_ctors and iterate through it, this disclosure exemplarily employs the following code implementation:

[0091]

[0092] In this code, the length of `__prof_ctors` can be calculated by the difference between `__prof_ctors_START_` and `__prof_ctors_END_`, which is used for traversal operations. `__prof_func_ptr` defines a function pointer type. `__prof_ctors_START_` and `__prof_ctors_END_` are ultimately backfilled by the device-side linker.

[0093] During the relocation phase after device-side linking is complete, the device-side linker fills in the start and end addresses of the linked segments into the corresponding symbols so that the final device-side code can obtain the correct segment lengths. It is important to note that the device-side linker fills in the host-side addresses, not the device-side addresses of the corresponding segments. This means that these addresses can only be used to calculate the length of the corresponding segments, and cannot be used to perform the corresponding load / store operations. This disclosure uses a similar method to obtain the lengths of the linked __prof_dtors and __llvm_prf_nms.

[0094] This disclosure also extends device-oriented compilers and linkers to support function pointer initialization lists. For example, in some instruction set architectures, __prof_ctors and __prof_dtors are implemented as arrays with initial values ​​on GDRAM. For example:

[0095] .gdram.align 8.b64__prof_ctors[1]={__llvm_profile_init_25E56857EF3E4A3E};

[0096] .gdram.align 8.b64__prof_dtors[1]={__llvm_profile_finalize_25E56857EF3E4A3E};

[0097] In this example, __llvm_profile_init_25E56857EF3E4A3E and __llvm_profile_finalize_25E56857EF3E4A3E are two device-side functions, corresponding to the initialization and unregistration functions of the compilation unit with module ID 0x25E56857EF3E4A3E.

[0098] During compilation, `__prof_ctors` and `__prof_dtors` are processed into two initialized GDRAM global arrays, and corresponding relocation entries are generated for their contents. During the relocation phase, the system initializes the contents of `__prof_ctors` and `__prof_dtors` based on the device-side addresses corresponding to these two functions, and then processes them according to the general initialization procedure for initialized GDRAM arrays.

[0099] Furthermore, the device-side linker disclosed herein performs a splicing operation on coverage-related segments during the linking process. These segments may include, for example, segments residing in CNBin (Cambricon Binary) such as __llvm_covfunc, __llvm_covmap, and __llvm_prf_names. Although the linking process for these segments is essentially the same as the linking process for general segments, mainly involving the splicing and merging of content, this step ensures the integrity of coverage data in multi-file linking scenarios.

[0100] Through the above design, this disclosure achieves comprehensive support for device-side coverage collection in multi-file linked scenarios. This method not only solves the problem of incomplete coverage data collection in existing technologies, but also improves the efficiency and accuracy of coverage collection. Especially in complex multi-file linked environments, this disclosure can ensure that the coverage data of each compilation unit is correctly initialized, collected, and unregistered, thereby providing more reliable data support for software testing and quality assurance.

[0101] Figure 12 A flowchart of a method 1200 performed in the post-processing stage according to an embodiment of the present disclosure is shown. This method 1200 is the final stage of code coverage analysis performed in a heterogeneous neural network processing unit (NPU) environment, and is particularly suitable for multi-file linked scenarios.

[0102] like Figure 12 As shown, in step S1202, the code coverage analysis tool first reads the linked binary file. This binary file contains coverage data collected during runtime, as well as various metadata information generated during the linking phase.

[0103] Next, the process proceeds to step S1204. In step S1204, the code coverage analysis tool checks the value of the coverage data offset sign (e.g., "fatbinData"). This step is to distinguish whether multiple file links exist. Specifically, this step includes: in step S1206, if the offset sign value is non-zero, it indicates that multiple file links exist, and the process jumps to step S1208. In step S1206, if the offset sign value is zero, it indicates that multiple file links do not exist, and the process jumps to step S1214. This design allows this disclosure to flexibly handle different linking scenarios.

[0104] If multiple files are linked, the process proceeds to step S1210. In step S1210, the code coverage analysis tool needs to handle the case of multiple file links specifically. Specifically, in step S1210, the offset for parsing the coverage data is calculated based on the value of the offset symbol (“fatbinData”) and the starting address of the coverage data segment (the .cn_fatbin segment). This calculation can be expressed as: Offset = Value of the fatbinData symbol - Address of the .cn_fatbin section. In step S1212, data parsing begins from the offset position of the coverage data segment. This ensures that, in the case of multiple file links, the code coverage analysis tool can accurately locate and parse the linked coverage data.

[0105] If no multi-file links exist, the process proceeds to step S1216. In step S1216, the code coverage analysis tool uses a standard parsing method, that is, it directly parses the data from the beginning of the coverage data segment. This is suitable for single-file or simple linking scenarios.

[0106] Finally, in step S1218, the code coverage analysis tool uses the parsed coverage data, combined with the code coverage mapping information, to generate the final code coverage report. This step involves complex data processing and analysis. The code coverage analysis tool needs to combine the collected coverage data (stored in the __llvm_prf_cnts segment) with the code coverage mapping information (stored in the __llvm_covmap segment), and utilize function name information (stored in the __llvm_prf_names segment) to generate a detailed and easy-to-read coverage report. This report typically includes information such as the number of times each function and each line of code was executed, and the overall code coverage percentage.

[0107] Through these steps, the post-processing method achieves accurate parsing and report generation of coverage data for multi-file linked programs on heterogeneous platforms. This method specifically considers the complexity of multi-file linking, correctly processing post-linked coverage data by checking and using symbols such as "fatbinData". Simultaneously, it fully utilizes various metadata generated during the compilation and linking phases, ensuring the accuracy and completeness of the coverage report. This design is applicable not only to simple single-file programs but also to complex multi-file linked scenarios, providing developers with comprehensive and detailed code coverage information, thus contributing to improved efficiency and quality of software testing.

[0108] After completion Figure 12Following the basic post-processing flow described, this disclosure further proposes optimizations to the llvm-cov tool to better support code coverage analysis in multi-file linking scenarios. These optimizations primarily focus on the parsing process of the linked binary files, particularly the handling of the .cn_fatbin segment. Regarding the aforementioned llvm-cov, it is a tool within the LLVM project used to analyze and report code coverage. Specifically, it leverages the LLVM compiler infrastructure to generate detailed coverage reports. The LLVM project is an open-source project for building compilers and related tools. Originally designed as a low-level virtual machine, LLVM has evolved into a comprehensive compiler infrastructure supporting multiple programming languages ​​and hardware platforms.

[0109] As mentioned earlier, in the binary file resulting from linking multiple files, the .cn_fatbin segment contains not only the fatbin files of each file before linking, but also the fatbin file of the linked file. This structure means that the traditional method of directly parsing .cn_fatbin using kernel function hash ID and architecture number may return the fatbin file before linking, resulting in errors in coverage data.

[0110] To address this issue, this disclosure proposes using a symbol maintained by the linker: fatbinData. This symbol points to the address of the linked fatbin section within the .cn_fatbin segment. The importance of the fatbinData symbol can be observed by analyzing the target binary file. For example, using the readelf -aW command to parse the target binary file yields the following information:

[0111]

[0112] In this example, the ELF address of the .cn_fatbin section is 0x409ba8, and its size is 0x18bf0 bytes. The value of the fatbinData symbol is 0x417738, which indicates the starting position of the linked fatbins in the .cn_fatbin section. Therefore, the address range [0x409ba9, 0x417738) stores the various fatbins before linking.

[0113] Based on this information, this disclosure optimizes the llvm-cov parsing process. The specific steps are as follows:

[0114] First, check the value of the fatbinData symbol.

[0115] If the value of the `fatbinData` symbol is not 0, it indicates that this is a binary file that has undergone multiple file linking. In this case:

[0116] a. Calculate the parsing offset = value of the fatbinData symbol - address of the .cn_fatbin section.

[0117] b. Start parsing from this offset position in the .cn_fatbin section data.

[0118] If the value of the `fatbinData` symbol is 0, it indicates that this is a binary file that has not been linked multiple times. In this case:

[0119] The parsing starts directly from the beginning of the .cn_fatbin section.

[0120] Using this method, the llvm-cov tool can correctly identify and parse binary files linked together, thus accurately obtaining coverage data. This design not only solves the problem of coverage data errors in multi-file linked scenarios but also maintains compatibility with non-multi-file linked binary files.

[0121] Furthermore, the method disclosed herein possesses excellent adaptability. Regardless of whether the target file being parsed is linked with multiple files, this method can correctly parse and obtain the corresponding coverage data. This versatility enables the invention to function effectively in various complex development and testing environments, providing developers with accurate and reliable code coverage information.

[0122] In summary, this disclosure effectively solves the problem of code coverage analysis in multi-file linking scenarios through optimizations to the llvm-cov tool, particularly in its innovations in handling .cn_fatbinsection and utilizing fatbinData symbols.

[0123] After implementing the method disclosed herein, the coverage collection problem in multi-file linked scenarios is effectively solved. The following is a specific example demonstrating the effectiveness of the method disclosed herein:

[0124] Consider two source files, b.mlu and a.mlu, which define and call a device-side function, respectively. After applying the method of this disclosure, the generated coverage report is as follows:

[0125] Coverage report for the b.mlu file:

[0126]

[0127] Coverage report for the a.mlu file:

[0128]

[0129]

[0130] This coverage report clearly shows the code execution status in both files. A "1" indicates that the corresponding line of code has been executed, while a blank space indicates that the line was not executed. This result demonstrates that the scheme disclosed in this publication can correctly collect and report code coverage information in multi-file linked scenarios.

[0131] Based on the foregoing description, those skilled in the art will understand that this application also discloses a device including a processor and a memory. Specifically, the memory can store program instructions for code coverage statistics, which, when executed by the processor, implement the functionality of this application. Figures 7-12 The described method steps. Furthermore, since the solution of this application can be implemented by computational program instructions, this application also discloses a computer-readable storage medium or computer program product storing a computer program / instructions for code coverage statistics, thereby achieving the combination... Figures 7-12 The described method and steps.

[0132] This disclosure not only maintains support for non-multi-file linked scenarios but also expands coverage collection support to multi-file linked scenarios. This comprehensiveness allows this disclosure to adapt to a wider range of development and testing environments. Furthermore, compared to GPU coverage schemes, this disclosure decouples the system from the host-side compiler. This design increases system flexibility, making the coverage collection process more independent and efficient.

[0133] Furthermore, this disclosure does not require generating an additional covinfo file (for storing coverage information) for each compilation unit. This approach significantly reduces file I / O overhead when dealing with a large number of compilation units, a particularly noticeable advantage in coverage testing of accelerated libraries using heterogeneous programming languages. Moreover, this disclosure leverages common language features such as support for symbol_START / END and function pointer lists. This means that the device-side assembler does not require specific customization, increasing the method's versatility and portability. Additionally, through the optimized use of the llvm-cov tool and the fatbinData symbol, this disclosure can accurately identify and process multi-file linked binaries, ensuring the accuracy of coverage data.

[0134] The solutions disclosed herein have been described in detail above with reference to the accompanying drawings. Depending on the application scenario, the devices or apparatus disclosed herein may include servers, cloud servers, server clusters, data processing devices, robots, computers, printers, scanners, tablet computers, smart terminals, PC devices, IoT terminals, mobile terminals, mobile phones, dashcams, navigators, sensors, cameras, video cameras, projectors, watches, headphones, mobile storage, wearable devices, visual terminals, autonomous driving terminals, vehicles, home appliances, and / or medical devices. The vehicles include airplanes, ships, and / or vehicles; the home appliances include televisions, air conditioners, microwave ovens, refrigerators, rice cookers, humidifiers, washing machines, lights, gas stoves, and range hoods; the medical devices include MRI scanners, ultrasound machines, and / or electrocardiographs. The devices or apparatus disclosed herein can also be applied in fields such as the Internet, IoT, data centers, energy, transportation, public management, manufacturing, education, power grids, telecommunications, finance, retail, construction sites, and healthcare.

[0135] Furthermore, the devices or apparatuses disclosed herein can also be used in application scenarios related to artificial intelligence, big data, and / or cloud computing, such as cloud computing, edge computing, and terminals. In one or more embodiments, the high-power devices or apparatuses according to the disclosed scheme can be applied to cloud devices (e.g., cloud servers), while the low-power devices or apparatuses can be applied to terminal devices and / or edge devices (e.g., smartphones or cameras). In one or more embodiments, the hardware information of the cloud devices and the hardware information of the terminal devices and / or edge devices are compatible with each other, so that suitable hardware resources can be matched from the hardware resources of the cloud devices to simulate the hardware resources of the terminal devices and / or edge devices based on the hardware information of the terminal devices and / or edge devices, so as to complete the unified management, scheduling, and collaborative work of end-to-cloud or cloud-edge-end integration.

[0136] It should be noted that, for the sake of brevity, this disclosure describes some methods and their embodiments as a series of actions and combinations thereof. However, those skilled in the art will understand that the solutions disclosed herein are not limited by the order of the described actions. Therefore, based on the disclosure or teachings of this document, those skilled in the art will understand that some steps can be performed in a different order or simultaneously. Furthermore, those skilled in the art will understand that the embodiments described in this disclosure can be considered optional embodiments, that is, the actions or modules involved are not necessarily essential for the implementation of one or more solutions disclosed herein. In addition, depending on the solution, the description of some embodiments in this disclosure may have different emphases. In view of this, those skilled in the art will understand that parts not described in detail in a certain embodiment of this disclosure can also be referred to the relevant descriptions of other embodiments.

[0137] In terms of specific implementation, based on the disclosure and teachings of this document, those skilled in the art will understand that several embodiments disclosed herein can also be implemented in other ways not disclosed herein. For example, regarding the various units in the device or apparatus embodiments described above, this document divides them based on logical functions, but in actual implementation, there may be other division methods. As another example, multiple units or components can be combined or integrated into another system, or some features or functions in a unit or component can be selectively disabled. Regarding the connection relationships between different units or components, the connections discussed above in conjunction with the accompanying drawings can be direct or indirect couplings between units or components. In some scenarios, the aforementioned direct or indirect couplings involve communication connections utilizing interfaces, where the communication interface can support electrical, optical, acoustic, magnetic, or other forms of signal transmission.

[0138] In this disclosure, the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units. The aforementioned components or units may be located in the same location or distributed across multiple network units. Furthermore, depending on actual needs, some or all of the units can be selected to achieve the purpose of the solution described in the embodiments of this disclosure. Additionally, in some scenarios, multiple units in the embodiments of this disclosure may be integrated into one unit or each unit may exist physically independently.

[0139] In some implementation scenarios, the integrated unit described above can be implemented as a software program module. If implemented as a software program module and sold or used as an independent product, the integrated unit can be stored in a computer-readable storage device (CMSDD). Therefore, when the disclosed solution is embodied in a software product (e.g., a computer-readable storage medium), the software product can be stored in a memory, which may include several instructions to cause a computer device (e.g., a personal computer, server, or network device) to execute some or all of the steps of the method described in the embodiments of this disclosure. The aforementioned memory may include, but is not limited to, various media capable of storing program code, such as USB flash drives, flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0140] In other implementation scenarios, the integrated units described above can also be implemented in hardware, i.e., as specific hardware circuits, which may include digital circuits and / or analog circuits. The physical implementation of the hardware structure of the circuit may include, but is not limited to, physical devices, which may include, but are not limited to, transistors or memristors. Therefore, the various devices described herein (e.g., computing devices or other processing devices) can be implemented using appropriate hardware processors, such as CPUs, GPUs, FPGAs, DSPs, and ASICs. Furthermore, the aforementioned storage unit or storage device can be any suitable storage medium (including magnetic storage medium or magneto-optical storage medium, etc.), such as resistive random access memory ("RRAM"), dynamic random access memory ("DRAM"), static random access memory ("SRAM"), enhanced dynamic random access memory ("EDRAM"), high bandwidth memory ("HBM"), hybrid memory cube ("HMC"), ROM, and RAM, etc.

[0141] The foregoing can be better understood in accordance with the following terms:

[0142] Clause A1. A method for code coverage collection, characterized in that it comprises:

[0143] During code compilation, each compilation unit is initialized and unregistered using a list of function pointers to generate initial code coverage data; and

[0144] During device-side linking, the linker is used to concatenate coverage-related segments to merge code coverage data updated by multiple compilation units after code execution.

[0145] Clause A2. The method according to Clause A1, characterized in that the function pointer list includes an initialization function pointer list for recording the initialization functions of each compilation unit and a deregistration function pointer list for recording the deregistration functions of each compilation unit.

[0146] Clause A3. The method according to Clause A2, characterized in that each item in the initialization function pointer list corresponds to an initialization function of a compilation unit, and each item in the unregister function pointer list corresponds to an unregister function of a compilation unit.

[0147] Clause A4. The method according to Clause A1, wherein the coverage-related segments include a function coverage information segment, a code coverage mapping segment, and / or a function name segment.

[0148] Clause A5. The method according to any one of Clauses A1-A4, characterized in that it further includes, when executing code on the device side, obtaining the length of the coverage-related segment by calculating the difference between the start address and the end address of the coverage-related segment.

[0149] Clause A6 describes the method according to Clause A1, wherein the initialization operation includes allocating memory for coverage data and performing numerical initialization.

[0150] Clause A7. The method according to Clause A1, characterized in that the deregistration operation includes the collection of coverage data and resource cleanup.

[0151] Clause A8. The method according to Clause A1, characterized in that the coverage data of compilation units are organized in a segment-based manner so that the linker can perform a merging operation.

[0152] Clause A9. The method according to Clause A1, characterized in that it further comprises:

[0153] In the post-processing stage of the code, the binary file after multi-file linking is parsed using code coverage analysis tools;

[0154] Based on the coverage data offset in the binary file, parsing begins from the linked coverage data;

[0155] Based on the parsed coverage data, a complete code coverage report containing the updated code coverage data is generated.

[0156] Clause A10. The method according to Clause A9, characterized in that, in the post-processing stage of the code, the method parses the binary file after multiple file links, and the method includes determining whether the binary file has been linked by multiple files by using the coverage data offset symbol in the binary file.

[0157] Clause A11. The method according to Clause A10, characterized in that, in response to determining that the value of the coverage data offset symbol is not zero, the offset for parsing the coverage data is calculated by subtracting the address of the coverage data segment in the binary file from the value of the coverage data offset symbol, and the coverage data is parsed starting from the position where the offset is added to the data of the coverage data segment in the binary file.

[0158] Clause A12. The method according to Clause A10, characterized in that, in response to determining that the value of the coverage data offset sign is zero, the coverage data is parsed starting from the beginning position of the coverage data segment.

[0159] Clause A13. A device for code coverage collection, comprising:

[0160] One or more processors; and

[0161] A memory storing computer instructions for code coverage collection in a heterogeneous neural network processing unit (NPU) environment, which, when executed by the one or more processors, cause the device to perform the method as described in any one of clauses A1-12.

[0162] Clause A14. A computer-readable storage medium storing computer instructions for code coverage collection, which, when executed by one or more processors, perform the method described in any one of Clauses A1-12.

[0163] Clause A15. A heterogeneous computing system comprising a host side and a device side, characterized in that the device side performs a method for code coverage collection as described in any one of Clauses A1-12.

[0164] While the embodiments of this disclosure are described above, the content is merely an example for the purpose of facilitating understanding of this disclosure and is not intended to limit the scope or application scenarios of this disclosure. Any person skilled in the art can make any modifications and changes in form and detail of the implementation without departing from the spirit and scope disclosed herein; however, the patent protection scope of this disclosure shall still be determined by the scope defined in the appended claims.

Claims

1. A method for code coverage collection, characterized in that, include: During code compilation, each compilation unit is initialized and unregistered using a list of function pointers to generate initial code coverage data. as well as During device-side linking, the linker is used to concatenate coverage-related segments to merge code coverage data updated by multiple compilation units after code execution.

2. The method according to claim 1, characterized in that, The function pointer list includes an initialization function pointer list for recording the initialization functions of each compilation unit and a deregistration function pointer list for recording the deregistration functions of each compilation unit.

3. The method according to claim 2, characterized in that, Each item in the initialization function pointer list corresponds to an initialization function of a compilation unit, and each item in the unregister function pointer list corresponds to an unregister function of a compilation unit.

4. The method according to claim 1, characterized in that, The coverage-related segments include the function coverage information segment, the code coverage mapping segment, and / or the function name segment.

5. The method according to any one of claims 1-4, characterized in that, It also includes, when executing code on the device side, obtaining the length of the coverage-related segment by calculating the difference between the start and end addresses of the coverage-related segment.

6. The method according to claim 1, characterized in that, The initialization operation includes allocating memory for the coverage data and performing numerical initialization.

7. The method according to claim 1, characterized in that, The deregistration operation includes the collection of coverage data and resource cleanup.

8. The method according to claim 1, characterized in that, The coverage data of compilation units is organized in a segment-based manner so that the linker can perform merging operations.

9. The method according to claim 1, characterized in that, Also includes: In the post-processing stage of the code, the binary file after multi-file linking is parsed using code coverage analysis tools; Based on the coverage data offset in the binary file, parsing begins from the linked coverage data; Based on the parsed coverage data, a complete code coverage report containing the updated code coverage data is generated.

10. The method according to claim 9, characterized in that, In the post-processing stage of the code, the method for parsing a binary file after multiple file links includes determining whether the binary file has undergone multiple file links by using the offset sign of the coverage data in the binary file.

11. The method according to claim 10, characterized in that, In response to the determination that the value of the coverage data offset sign is not zero, the offset for parsing the coverage data is calculated by subtracting the address of the coverage data segment in the binary file from the value of the coverage data offset sign, and the parsing of the coverage data begins from the position where the offset is added to the data of the coverage data segment in the binary file.

12. The method according to claim 10, characterized in that, If the value of the offset sign of the coverage data is zero, the coverage data is parsed starting from the beginning of the coverage data segment.

13. A device for code coverage collection, comprising: One or more processors; as well as A memory storing computer instructions for code coverage collection in a heterogeneous neural network processing unit (NPU) environment, wherein when the computer-executable instructions are executed by the one or more processors, the device performs the method as described in any one of claims 1-12.

14. A computer-readable storage medium storing computer instructions for code coverage collection, which, when executed by one or more processors, perform the method as described in any one of claims 1-12.

15. A heterogeneous computing system, comprising a host side and a device side, characterized in that, The device side performs the method for code coverage collection as described in any one of claims 1-12.

Images