CN118260185A - 代码覆盖率统计的方法及其相关产品 - Google Patents

Abstract

本公开涉及一种代码覆盖率统计的方法及其相关产品，其中该相关产品包括代码覆盖率统计的设备和计算机可读存储介质。该设备可以包括在组合处理装置的计算处理装置中，该计算处理装置可以包括一个或多个数据处理装置。前述的组合处理装置还可以包括接口装置和其他处理装置。所述计算处理装置与其他处理装置进行交互，共同完成用户指定的计算操作。组合处理装置还可以包括存储装置，该存储装置分别与设备和其他处理装置连接，用于存储该设备和其他处理装置的数据。通过本公开的方案，实现对异构编程代码覆盖率统计的支持并且有助于提高代码鲁棒性和增加异构编程代码的易读性。

Description

代码覆盖率统计的方法及其相关产品

技术领域

本公开一般地涉及计算机领域。更具体地，本公开涉及一种代码覆盖率统计的方法、用于执行前述方法的设备和计算机可读存储介质。

背景技术

在异构计算领域中，为了方便用户编程，编译器可以支持同一份代码中进行主机侧和设备侧的编程，也即采用异构编程代码。可以看出的是，这种异构编程代码较为复杂，其不仅对鲁棒性要求更高，且增加了相关人员理解代码逻辑的难度。在相关技术中，针对代码的覆盖率统计，可以辅助相关人员来理解异构编程代码。然而，现有技术仅支持主机侧的覆盖率采集，而缺乏异构编程代码覆盖率支持的方案。鉴于此，现有技术需要一种改进的方案来满足异构编程代码覆盖率统计的需求。

发明内容

鉴于上述背景技术部分所提及的技术问题，本公开提出一种用于对异构编程代码进行覆盖率统计的方案。利用本公开的方案，可以基于异构编程代码所得的主机侧覆盖率文件和设备侧覆盖率文件来生成统一覆盖率报告，从而实现异构编程代码覆盖率的有效统计。为此，本公开在如下的多个方面中提供解决用于对异构编程代码进行覆盖率统计的方案。

在第一方面中，本公开提供了一种用于对代码覆盖率统计的方法，其中所述代码包括主机侧代码和设备侧代码，所述方法包括：分别对所述主机侧代码和所述设备侧代码执行编译操作，以得到可执行文件，其中，所述主机侧代码和所述设备侧代码包含用于获得覆盖率信息的插桩代码，所述可执行文件能够在包含主机侧和设备侧的异构计算平台上运行；根据所述可执行文件的运行结果，生成主机侧覆盖率文件和设备侧覆盖率文件；以及基于所述主机侧覆盖率文件和所述设备侧覆盖率文件生成统一覆盖率报告。

在第二方面中，本公开提供了一种代码覆盖率统计的设备，包括：一个或多个处理器；以及存储器，所述存储器中存储有计算机可执行指令，当所述计算机可执行指令由所述一个或多个处理器运行时，使得所述设备执行上文所述及其下文将讨论到的多个实施例。

在第三方面中，本公开提供了一种计算机可读存储介质，其存储有代码覆盖率统计的计算机程序指令，当所述计算机程序指令由一个或多个处理器执行时，使得实现上文的方法及其下文将讨论到的多个实施例。

通过本公开如上多个方面中所提供的方案，可以实现对异构编程代码覆盖率统计的有效支持。具体地，本公开的方案通过获取异构编程代码中的主机侧代码和设备侧代码分别对应的主机侧覆盖率文件和设备侧覆盖率文件，并且通过主机侧覆盖率文件和设备侧覆盖率文件生成统一覆盖率报告，从而实现对异构编程代码覆盖率的有效统计。由此，相关人员便于根据统一覆盖率报告更好地理解异构编程代码逻辑，并且同时可以根据统一覆盖率报告适应性调整代码，从而有助于提高代码的鲁棒性。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，并且相同或对应的标号表示相同或对应的部分，其中：

图1是示意性示出根据本公开实施例的用于对异构编程代码进行覆盖率统计的方法的简化流程图；

图2是示意性示出根据本公开实施例的用于对异构编程代码进行覆盖率统计的方法细节的流程图；

图3是示意性示出图1和图2中异构编程代码的编译过程的具体流程图；

图4是示意性示出根据本公开实施例的运行编译期插桩后的内核函数的两种实施方式的简化流程图；

图5是示意性示出根据本公开实施例的生成统一覆盖率报告的详细流程图；

图6是示出根据本公开实施例的数据流编程的软硬件架构的结构示意图；

图7是示出根据本公开实施例的板卡的结构图；

图8是示出根据本公开实施例的组合处理装置的结构图；

图9是示出根据本公开实施例的计算装置的内部结构示意图；

图10是示出根据本公开实施例的处理器核的内部结构示意图；以及

图11是示出根据本公开实施例的不同集群的处理器核间的数据写入过程示意图。

具体实施方式

下面将结合本公开实施方式中的附图，对本公开实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本公开一部分实施方式，而不是全部的实施方式。基于本公开中的实施方式，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式，都属于本公开保护的范围。

应当理解，本公开的权利要求、说明书及附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。本公开的说明书和权利要求书中使用的术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本公开说明书中所使用的术语仅仅是出于描述特定实施方式的目的，而并不意在限定本公开。如在本公开说明书和权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。还应当进一步理解，在本公开说明书和权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

如前文提到的，本公开的方案可以应用于异构计算领域，例如由主机侧(如CPU等)和设备侧(如人工智能芯片、GPU等)所构成的异构计算平台，其中，主机侧和设备侧的硬件处理器可以具有不同的指令集架构。就本公开的应用场景而言，异构计算平台可以支持异构编程代码。例如，该异构编程代码可以包括主机侧代码和设备侧代码，其中，主机侧代码能够在主机侧运行，设备侧代码能够在设备侧运行。在该异构编程代码的实际运行过程中，设备侧代码及其所需的数据首先从主机侧拷贝至设备侧(如通过驱动程序)，设备侧对上述设备侧代码进行执行，以获得相应运行的执行结果，最后再将该执行结果从设备侧拷贝至主机侧。

由此，异构编程代码相对较为复杂，相关人员不易理解异构编程代码的逻辑，进而无法确保代码的鲁棒性。为了克服如此处以及背景技术部分所讨论的现有技术缺陷，本公开的方案提出可以生成关于异构编程代码的统一覆盖率报告，由此实现对异构编程代码覆盖率统计的支持并且有助于提高代码鲁棒性和便于相关人员对异构编程代码的解读及优化。

本公开实施例中的设备侧可以是人工智能芯片或板卡等。图7示出本披露实施例的一种板卡700的结构示意图。如图7所示，板卡700包括芯片(或称“处理芯片”)701，其是一种系统级芯片(System on Chip，SoC)，或称片上系统，集成有一个或多个组合处理装置，组合处理装置是一种人工智能运算单元，用以支持各类深度学习和机器学习算法，满足计算机视觉、语音、自然语言处理、数据挖掘等领域复杂场景下的智能处理需求。特别是深度学习技术大量应用在云端智能领域，云端智能应用的一个显著特点是输入数据量大，对平台的存储能力和计算能力有很高的要求，此实施例的板卡700适用在云端智能应用，具有庞大的片外存储、片上存储和大量的计算能力。

芯片701通过对外接口装置702与外部设备703相连接。外部设备703例如是服务器、计算机、摄像头、显示器、鼠标、键盘、网卡或WIFI接口等。待处理的数据可以由外部设备703通过对外接口装置702传递至芯片701。芯片701的计算结果可以经由对外接口装置702传送回外部设备703。根据不同的应用场景，对外接口装置702可以具有不同的接口形式，例如PCIe接口等。

板卡700还包括用于存储数据的存储器件704，其包括一个或多个存储单元705。存储器件704通过总线与控制器件707和芯片701进行连接和数据传输。板卡700中的控制器件706配置用于对芯片701的状态进行调控。为此，在一个应用场景中，控制器件706可以包括单片机(Micro Controller Unit，MCU)。

图8是示出此实施例的芯片701中的组合处理装置800的结构图。如图8中所示，组合处理装置800包括计算装置801、接口装置802、处理装置803和DRAM 804。

计算装置801配置成执行用户指定的操作，主要实现为单核智能处理器或者多核智能处理器，用以执行深度学习或机器学习的计算，其可以通过接口装置802与处理装置803进行交互，以共同完成用户指定的操作。

接口装置802用于在计算装置801与处理装置803间传输数据和控制指令。例如，计算装置801可以经由接口装置802从处理装置803中获取输入数据，写入计算装置801片上的存储装置。进一步，计算装置801可以经由接口装置802从处理装置803中获取控制指令，写入计算装置801片上的控制缓存中。替代地或可选地，接口装置802也可以读取计算装置801的存储装置中的数据并传输给处理装置803。

处理装置803作为通用的处理装置，执行包括但不限于数据搬运、对计算装置801的开启和/或停止等基本控制。根据实现方式的不同，处理装置803可以是中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)或其他通用和/或专用处理器中的一种或多种类型的处理器，这些处理器包括但不限于数字信号处理器(digital signal processor，DSP)、专用集成电路(application specificintegrated circuit，ASIC)、现场可编程门阵列(field-programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，并且其数目可以根据实际需要来确定。如前所述，仅就本披露的计算装置801而言，其可以视为具有单核结构或者同构多核结构。然而，当将计算装置801和处理装置803整合共同考虑时，二者视为形成异构多核结构。

DRAM 804用以存储待处理的数据，为DDR内存，大小通常为16G或更大，用于保存计算装置801和/或处理装置803的数据。

图9示出了计算装置801的内部结构示意图。计算装置801用以处理计算机视觉、语音、自然语言、数据挖掘等输入数据，图中的计算装置801采用多核分层结构设计，计算装置801作为一个片上系统，其包括多个集群(cluster)，每个集群又包括多个处理器核，可以用于执行本公开下发的任务。换言之，计算装置801是以片上系统-集群-处理器核的层次所构成的。

以片上系统的层级来看，如图9所示，计算装置801包括外部存储控制器901、外设通信模块902、片上互联模块903、同步模块904以及多个集群905。

外部存储控制器901可以有多个，在图中示例性地展示2个，其用以响应处理器核发出的访问请求，访问外部存储设备，例如图8中的DRAM804，从而自片外读取数据或是将数据写入。外设通信模块902用以通过接口装置802接收来自处理装置803的控制信号，启动计算装置801执行任务。片上互联模块903将外部存储控制器901、外设通信模块902及多个集群905连接起来，用以在各个模块间传输数据和控制信号。同步模块904是一种全局同步屏障控制器(global barrier controller，GBC)，用以协调各集群的工作进度，确保信息的同步。多个集群905是计算装置801的计算核心，在图中示例性地展示4个，随着硬件的发展，本披露的计算装置801还可以包括8个、16个、64个、甚至更多的集群905。

以集群的层级来看，如图9所示，每个集群905包括多个处理器核(IPU core)906及一个存储核(MEM core)907。

处理器核906在图中示例性地展示4个，本披露不限制处理器核906的数量。其内部架构如图9所示。每个处理器核906包括三大模块：控制模块91、运算模块92及存储模块93。

控制模块91用以协调并控制运算模块92和存储模块93的工作，以完成深度学习的任务，其包括取指单元(instruction fetch unit，IFU)1011及指令译码单元(instructiondecode unit，IDU)1012。取指单元1011用以获取来自处理装置803的指令，指令译码单元1012则将获取的指令进行译码，并将译码结果作为控制信息发送给运算模块92和存储模块93。

运算模块92包括向量运算单元1021及矩阵运算单元1022。向量运算单元1021用以执行向量运算，可支持向量乘、加、非线性变换等复杂运算；矩阵运算单元1022负责深度学习算法的核心计算，即矩阵乘及卷积。

存储模块93用来存储或搬运相关数据，包括神经元存储单元(neuron RAM，NRAM)1031、权值存储单元(weight RAM，WRAM)1032、输入/输出直接内存访问模块(input/outputdirect memory access，IODMA)1033、搬运直接内存访问模块(move direct memoryaccess，MVDMA)1034。NRAM 1031用以存储供处理器核906计算的输入、输出数据及中间结果；WRAM 1032则用以存储深度学习网络的权值；IODMA 1033通过广播总线909控制NRAM1031/WRAM 1032与DRAM 804的访存；MVDMA 1034则用以控制NRAM 1031/WRAM 1032与SRAM908的访存。

回到图9，存储核907主要用以存储和通信，即存储处理器核906间的共享数据或中间结果、以及执行集群905与DRAM 804之间的通信、集群905间彼此的通信、处理器核906间彼此的通信等。在其他实施例中，存储核907具有标量运算的能力，用以执行标量运算。

存储核907包括共享存储单元(SRAM)908、广播总线909、集群直接内存访问模块(cluster direct memory access，CDMA)910及全局直接内存访问模块(global directmemory access，GDMA)911。SRAM 908承担高性能数据中转站的角色，在同一个集群905内不同处理器核906之间所复用的数据不需要通过处理器核906各自向DRAM 804获得，而是经SRAM 908在处理器核906间中转，存储核907只需要将复用的数据从SRAM 908迅速分发给多个处理器核906即可，以提高核间通讯效率，亦大大减少片上片外的输入/输出访问。

广播总线909、CDMA 910及GDMA 911则分别用来执行处理器核906间的通信、集群905间的通信和集群905与DRAM 804的数据传输。以下将分别说明。

广播总线909用以完成集群905内各处理器核906间的高速通信，此实施例的广播总线909支持核间通信方式包括单播、多播与广播。单播是指点对点(即单一处理器核至单一处理器核)的数据传输，多播是将一份数据从SRAM 908传输到特定几个处理器核906的通信方式，而广播则是将一份数据从SRAM 908传输到所有处理器核906的通信方式，属于多播的一种特例。

CDMA 910用以控制在同一个计算装置801内不同集群905间的SRAM 908的访存。图11示出当一个处理器核欲将数据写入至另一个集群的处理器核时的示意图，以说明CDMA910的工作原理。在此应用场景中，同一个计算装置包括多个集群，为方便说明，图中仅展示集群0与集群1，集群0与集群1分别包括多个处理器核，同样为了说明方便，图中的集群0仅展示处理器核0，集群1仅展示处理器核1。处理器核0欲将数据写入至处理器核1。

首先，处理器核0发送单播写请求将数据写入本地的SRAM 0中，CDMA 0作为主(master)端，CDMA 1作为从(slave)端，主端向从端推送写请求，即主端发送写地址AW和写数据W，将数据传送到集群1的SRAM 1中，接着从端发送写响应B作为回应，最后集群1的处理器核1发送单播读请求将数据从SRAM 1中读取出来。

回到图9，GDMA 911与外部存储控制器901协同，用以控制集群905的SRAM 908到DRAM 804的访存，或是将数据自DRAM 804读取至SRAM 908中。从前述可知，DRAM 804与NRAM1031或WRAM 1032间的通信可以经由2个渠道来实现。第一个渠道是通过IODAM 1033直接联系DRAM 804与NRAM 1031或WRAM 1032；第二个渠道是先经由GDMA 911使得数据在DRAM 804与SRAM 908间传输，再经过MVDMA1034使得数据在SRAM 908与NRAM 1031或WRAM 1032间传输。虽然表面上看来第二个渠道需要更多的元件参与，数据流较长，但实际上在部分实施例中，第二个渠道的带宽远大于第一个渠道，因此DRAM 804与NRAM 1031或WRAM 1032间的通信通过第二个渠道可能更有效率。本公开的实施例可根据本身硬件条件选择数据传输渠道。

在其他实施例中，GDMA 911的功能和IODMA 1033的功能可以整合在同一部件中。本披露为了方便描述，将GDMA 911和IODMA 1033视为不同部件，对于本领域技术人员来说，只要其实现的功能以及达到的技术效果与本公开类似，即属于本公开的保护范围。进一步地，GDMA 911的功能、IODMA 1033的功能、CDMA 910的功能、MVDMA 1034的功能亦可以由同一部件来实现，同样地，只要其实现的功能以及达到的技术效果与本披露类似，均属于本公开的保护范围。

以上结合图7-图11对本公开的硬件架构及其内部结构进行了详细的描述。可以理解的是上述描述仅仅是示例性的而非限制性的。根据不同的应用场景和硬件规格，本领域技术人员也可以对本公开的板卡(或者说人工智能设备)及其内部结构进行改变，而这些改变依然落入本公开的保护范围内。除了图7-图11所示出的硬件架构，本公开的方案还涉及软硬件架构，下面将对其进行描述。

图6示出本公开一实施例中软硬件架构的设计图。从图中所示可以看出，此实施例中的软硬件架构可以包括AI处理器601、驱动及操作系统602、编译器及编程语言603、库604、框架层605和应用层606。可以理解的是，这里的软硬件架构可以应用于本申请的人工智能计算系统或异构计算平台中。

具体来说，AI处理器601(其例如可以包括在下文结合附图所描述的板卡中)在硬件设计上同时考虑运算优化和数据搬运优化。为此，其采用定制化的运算单元来加速运算，并且使用片上存储来加速数据搬运，从而获得极高的性能和能效比。另外，为了支持各种算法优化，AI处理器601可以具有定制化的运算单元和指令集，其中指令集可以提供不同粒度的运算指令(标量、向量和/或矩阵)。进一步，当考虑算法访存特征、硬件成本、验证难度等多方面的因素，则可以采用片上存储的方式，并且优化数据搬运。在实际操作中，本公开的AI处理器可以实现超出主流GPU(图形处理单元)几十倍以上的速度。

驱动及操作系统602主要负责实现任务在AI处理器601上的调度。该调度操作例如可以实现根据任务优先级进行调度、多设备之间的通信及同步等。对于编译后的程序，其可以通过操作系统和驱动实现待实施的任务在特定处理器上的调度执行，包括但不限于如下的操作：分配、释放设备内存、实现设备之间数据传输、维护任务队列，以及根据优先级调度任务，实现多设备间的同步和协作。

编译器及编程语言603可以是针对AI处理器601的指令集研发的一套汇编语言。在应用中，其可以将面向AI处理器601开发的深度学习算子翻译成处理器指令组合，以便于调用AI处理器601，从而高效地使用该AI处理器601。在一些应用场景中，可以利用编译器执行编译的中间表达阶段来优化编译。

库604可以包括运行时库614和机器学习库624。在一个实施场景中，前述库604可以使用AI处理器601的指令集并根据AI处理器601的指令集进行部分优化，以提高算子的运行速度。运行时库614可以是针对AI处理器601专门开发的一套高性能算子库，并且其可以用于完成通用处理器和人工智能处理器之间的交互。进一步，该运行时库614还可以提供一套面向人工智能处理器的接口。对于机器学习库624，其可以用于在人工智能处理器上加速各种机器学习或者深度学习算法。具体地，该机器学习库624可以提供一套高效、通用、灵活且可扩展的编程接口，其上层的机器学习应用可以直接采用各种编程框架(例如pytorch、TensorFlow、Caffe、MXNet等)的编程接口，也可以使用机器学习库624提供的接口来直接编程。另外，本公开的机器学习库624可以方便硬件平台的调用，而运行时库614可以实现一些基础的常用算子，如卷积、池化等各种操作。

框架层605可以增加对面向AI处理器开发的算子的封装，并且主要是对运行时库614的算子的封装。除此之外，框架层605还可以修改相关的任务调度或内存管理等部分。在一个应用场景中，框架层605可以采用TensorFlow等框架的架构。

下面结合附图来详细描述本公开的具体实施方式。

图1是示意性示出根据本公开实施例的用于对异构编程代码进行覆盖率统计的方法100的简化流程图。需要说明的是，这里的异构编程代码可以包括主机侧代码和设备侧代码，其中，主机侧代码能够在主机侧运行，设备侧代码能够在设备侧运行。本公开实施例的执行主体可以为主机侧，例如编译器。

如图1所示，在步骤S102处，编译器可以分别对异构编程代码中的主机侧代码和设备侧代码执行编译操作，以得到可执行文件。其中，前述的主机侧代码和设备侧代码中可以包括用于获得覆盖率信息的插桩代码。在一些实施例中，在实现覆盖测试的过程中，往往需要知道某些信息，例如代码中可执行语句被执行(即被覆盖)的情况、代码执行的路径、变量的引用、定义等。若想要获取这类信息，需要跟踪被测代码的执行过程。为此，本公开提出采用插桩技术来完成主机侧代码和设备侧代码中覆盖率的统计分析。具体来说，编译器可以分别在主机侧代码和设备侧代码中插入用于获取覆盖率信息的代码，以实现插桩操作。可选地，用户可以通过编译选项对代码中(主机侧代码或设备侧代码)的每个函数或每个基本块进行插桩。可选地，用户可以根据通过编译选项来控制对代码(主机侧代码或设备侧代码)中的特定函数或特定的基本块进行插桩，该特定函数或特定基本块可以是用户关心的影响代码覆盖率的函数。这样，本公开通过仅对代码中部分函数或基本块进行插桩获得其相应的覆盖率文件，可以减少覆盖率文件对存储资源的占用。具体将在下文中结合图3进行说明。进一步，前述的编译操作例如可以包括将经插桩后的主机侧代码和设备侧代码转换机器码(或称机器代码)，即可执行文件。

具体地，如图3所示，异构编程代码为包含主机侧代码和设备侧代码的test.mlu，编译器执行对test.mlu的编译工作。编译器可以包括主机侧编译器和设备侧编译器，其中，主机侧编译器用于对主机侧代码进行插桩，并对插桩后的代码进行编译操作，以获得主机侧代码对应的主机侧可执行文件test.o。设备侧编译器可以对设备侧代码进行插桩，并对插桩后的代码进行编译操作，以获得设备侧代码对应的设备侧可执行文件。如图3所示，设备侧编译器可以包括编译器和汇编器两级，编译器将test.mlu中的设备侧代码编译成汇编代码(例如test.s)，然后汇编器将汇编代码编译成可执行文件text.cnbin。最后，链接器可以将上述主机侧可执行文件和设备侧可执行文件链接生成上述可执行文件。其中，主机侧可执行文件能够在主机侧运行，设备侧可执行文件能够在设备侧运行。需要说明的是，这里对异构编程代码的编译细节的相关描述仅仅是示例性的，本公开的方案并不受此限制。例如，根据本公开的教导，本领域技术人员也可以对所采用的工具链、编译器的具体类型进行适当的调整，以适应实际的需要。

接着，返回图1。在步骤S104处，编译器可以根据所述可执行文件的运行结果，以得到主机侧覆盖率文件和设备侧覆盖率文件。在获取到关于异构编程代码的可执行文件后，异构计算平台可以运行该可执行文件，具体地，主机侧可以将设备侧可执行文件下发给设备侧进行运行，从而主机侧运行主机侧可执行文件test.o，设备侧运行设备侧可执行文件text.cnbin，以获得运行结果。由于该主机侧代码和设备侧代码中均包括用于统计覆盖率信息的插桩代码，因此，在异构计算平台对上述代码的运行过程中，可以获得相应代码的覆盖率数据，从而根据覆盖率数据获得主机侧覆盖率文件和设备侧覆盖率文件。

最后，在步骤S106处，可以基于前述的主机侧覆盖率文件和设备侧覆盖率文件生成统一覆盖率报告。

基于上文结合图1的描述，可以理解的是，本公开的方案通过获取异构编程代码中的主机侧代码和设备侧代码分别对应的主机侧覆盖率文件和设备侧覆盖率文件，并且通过主机侧覆盖率文件和设备侧覆盖率文件生成统一覆盖率报告，从而实现对异构编程代码覆盖率的有效统计。如本领域技术人员所知，代码覆盖率是对程序源代码测试程度的一种度量。本公开的方案通过生成统一覆盖率报告，可以清楚地展示出异构编程代码的覆盖率相关信息，从而便于相关人员更好理解异构编程代码逻辑，由此也使得异构编程代码具备良好的易读性。另外，拥有高代码覆盖率的异构编程代码相较于覆盖率低的异构编程代码而言，其包含软件漏洞等的可能性更低。由此，统一覆盖率报告有助于相关人员适应性调整代码，从而提高代码鲁棒性和编程人员的编程效率。

图2是示意性示出根据本公开实施例的用于对异构编程代码进行覆盖率统计的方法200细节的流程图。需要说明的是，方法200可以理解为是方法100的进一步限定或拓展，也即图1所示方法100的一种可能实施方式。因此，前文结合图1的相关描述同样也适用于下文。

如图2所示，在步骤S202处，编译器可以对原始主机侧代码和原始设备侧代码执行插桩操作，其中，原始主机侧代码和原始设备侧代码是指未执行插桩操作之前的代码。具体地，在一些实施例中，可以利用预设编译选项分别对主机侧代码和设备侧代码执行插桩操作，以获得包含插桩代码的主机侧代码和设备侧代码。其中，前述的插桩代码可以是指用于统计覆盖率信息的计数器。在一些实施场景下，本公开实施例的编译器可以分别依据主机侧代码和设备侧代码的控制流图实现对相应代码的插桩操作。这样，在代码执行的过程中，可以根据插桩后的代码分配所需的内存，并在程序执行到该插桩代码的位置时，将相应的计数器执行加1操作，然后再存回到对应的内存位置处。

同时编译器还可以分别生成相应的代码映射关系。该代码映射关系可以理解为是指插桩代码(如计数器)与相应的原始主机侧代码或原始设备侧代码之间的映射关系。由于在生成覆盖率报告时需要知道每个计算器的值以及原始代码和计数器之间的映射关系，因而该映射关系可以用于在覆盖率报告中整合收集到的覆盖率信息。

如前所述，本公开的异构编程代码可以包括前述的主机侧代码和设备侧代码。在一些实施例中，具体可以使能预设编译选项(例如-fprofile-instr-generate-fcoverage-mapping选项等)分别对主机侧代码和设备侧代码执行插桩，并分别生成相应的代码映射关系。例如，编译器可以在主机侧代码中插入完成相应工作的代码以完成插桩操作，并对经插桩后的主机侧代码进行编译，以获得相应的可执行文件。编译器可以在设备侧代码中插入完成相应工作的代码以完成插桩操作，并对经插桩后的设备侧代码进行编译，以获得相应的可执行文件。

在得到如上所述的可执行文件后，异构计算平台接着可以运行可执行文件，以得到可执行文件的运行结果。接着，在步骤S204处，编译器根据所述可执行文件的运行结果，生成得到主机侧覆盖率文件和设备侧覆盖率文件。在一些实施例中，在主机侧代码运行阶段，可以通过环境变量(例如LLVM_PROFILE_FILE等)对主机侧覆盖率文件进行设置。相对应地，在设备侧代码运行阶段，可以运行插桩和编译操作后的设备侧代码，以获得设备侧覆盖率文件。为了优化该统一覆盖率报告，本公开实施例可以通过以下实施例的一种或多种的组合来实现设备侧覆盖率文件的优化。

在一些实施例中，设备侧在运行过程中可以依照设备侧的预设文件格式配置设备侧覆盖率文件，以使得主机侧可以根据设备侧的执行结果生成相应的设备侧覆盖率文件。

具体地，在每个内核函数(“kernel”)运行结束后，设备侧可以按照预设的文件格式配置设备侧覆盖率文件。其中，为了提高内核函数在设备侧的运行效率，每个内核函数可以被实例化为至少一个任务(task)，本公开实施例可以在内核函数运行结束后，通过预设的文件格式按照任务task的粒度配置覆盖率文件。

具体地，上述预设的文件格式以特定的方式组合如下覆盖率信息中的一种或多种：文件名、文件生产者、内核函数标识、任务标识、设备侧型号以及内核函数运行情况等等。在内核函数进行离线处理时，上述命名方式可以对不同的内核函数进行区分。

例如，设备侧覆盖率文件的文件格式可以如下：

CNPGO_DATA_IPU/MPU_${threadID}_${ctxID}_${mluArch}_${kerne lHashID}_${taskID}_${counter}。

其中，CNPGO_DATA_为文件名，IPU/MPU用于区分该设备侧覆盖率文件的生产者，该标识与具体的设备侧硬件包含的处理单元相关，本公开实施例的设备可以包括处理核和存储核，具体可参见上文图9所示。mluArch用于表示设备侧型号，如用于区分不同的设备侧架构。kernelHashID为内核函数标识，用于区分不同的内核函数；taskID为任务标识，用于区分不同的任务。内核函数运行情况可以包括内核函数的下发次数等。具体地，内核函数的下发情况可以通过参数进行表示：ctxID(也即context ID)用于区分不同或相同内核函数在不同硬件队列内运行的情况，其中context表示上下文描述；counter用于区分同一队列(“queue”)内同一内核函数多次运行的情况，其中queue表示用于执行任务的队列。可以理解的是，按照任务粒度生成覆盖率文件有助于用户了解每个队列中每个内核在每次运行中各个任务的运行情况。需要说明的是，这里对设备侧覆盖率文件的命名方式的细节性描述仅是示例性的说明，其具体命名方式可以根据应用需求进行适应性的调整。

基于上述的覆盖率文件格式，用户可以通过检索内核函数标识或任务标识从而快速定位相应的覆盖率信息。本公开实施例通过上述细粒度的方式配置设备侧覆盖率文件，能够精确的表示出内核函数级别，甚至是任务级别的覆盖率信息，从而方便用户定位问题，方便使用。

进一步地，在一些实施例中，设备侧覆盖率文件的缓存可以放置在设备侧的本地内存中。响应于每个内核函数运行结束，可以将本地内存中的设备侧覆盖率文件复制至主机侧。然后，基于主机侧中的设备侧覆盖率文件的缓存，生成设备侧覆盖率文件。

在一些实施例中，在实现覆盖率统计过程中，用户可以通过环境变量设置各个内核函数对应的覆盖率文件的缓存大小，并且所有内核函数的各任务都可以使用相同的覆盖率文件缓存空间。但是鉴于在一些场景中，设备接口(例如驱动程序接口)在插件加载操作后不支持修改环境变量，因此用户在使用过程中要按照下发内核函数中所需要的最大覆盖率文件缓存去进行声明，以用于存储设备侧覆盖率文件。由于内核函数的用于存储覆盖率文件的缓存大小与设备侧代码复杂程度相关，因此不同内核函数所需要的用于存储覆盖率文件的缓存大小差别较大。可以看出，前述情形不仅对用户使用来说不友好，并且会造成动态随机存取存储器资源浪费。

鉴于上述情形，设备侧可以根据设备侧代码自适应地在本地内存中分配相应的缓存空间，以用于存储上述的设备侧覆盖率文件。即本公开的方案能够动态计算内核函数所需的设备侧覆盖率文件的缓存大小。具体地，主机侧编译器可以在编译期对覆盖率文件相关的缓存大小进行扫描，计算内核函数所需的覆盖率文件的缓存大小，并将该缓存大小记录在内核函数中(例如，该缓存大小可以记录在内核函数的配置项kernel config段内)。之后，主机侧可以将该内核函数对应的可执行文件下发至设备侧，设备侧可以运行该内核函数。响应于内核函数运行，设备侧可以首先对内核函数进行解析，获得相应的缓存大小信息，并根据计算得到的设备侧覆盖率文件的缓存大小进行自适应缓存分配。通过这种方式，不仅提升了用户友好度，并且还能有效节省内存。由此，本公开的方案无需用户来统一设置覆盖率文件所需的缓存大小。

在一些实施场景中，可能还存在下发的内核函数数量过多的情形。对此，为了提高运行效率，以及减少对设备侧本地内存(例如动态随机存取存储器)的使用量，本公开实施例还可以进一步优化运行阶段。

图4是示意性示出根据本公开实施例的运行编译期插桩后的内核函数的两种实施方式的简化流程图。其中，每个内核函数的运行过程包括主机侧的数据准备阶段(例如图4中主机侧侧的pre_kernel阶段)、设备侧的内核运行阶段(例如图4中设备侧的kernel阶段)和主机侧的数据回传阶段(例如图4中主机侧的post_kernel阶段)。

如图所示，在图4中的方式一过程中：响应于任一内核函数对应的数据回传阶段(post_kernel阶段)完成，主机侧启动下一内核函数的数据准备阶段(pre_kernel阶段)。具体地，主机侧在pre_kernel阶段可以用来准备设备侧覆盖率文件所需的缓存以及内核函数中各个任务所需的缓存，例如生成malloc函数，并将前述缓存的首地址和相应的缓存大小通过隐藏参数的形式传给设备侧，以用于防止将缓存中的数据写回到全局动态随机存取存储器(简称global DRAM)时可能出现的越界情况。设备侧可以根据接收到内存分配指令及其包含的参数进行相应内存的分配，并运行接收到的内核函数kernel，即图4中的kernel阶段。在设备侧kernel运行结束后，主机侧post_kernel阶段可以将设备侧覆盖率文件的缓存从设备侧拷贝回，并按照上述预设的文件格式生成不同的设备侧覆盖率文件，具体可参见上文。在post_kernel阶段完成后，主机侧再进行同一个队列内下一个kernel的pre_kernel阶段。需要说明的是，上述的任一内核函数和下一内核函数属于同一队列。另外，任一内核函数和下一内核函数可以属于同一内核或属于不同内核。

进一步地，在一些实施例中，为了提升内核运行的效率，主机侧在使能覆盖率功能时可以对内核运行的过程进一步优化。在如图4中的方式二示出了对内核运行过程的进一步优化。与上述方式一不同，主机侧可以在任一内核函数对应的数据回传阶段执行过程中，同步启动与下一内核函数的数据准备阶段。可以理解的是，与方式一不同，方式二中主机侧在post_kernel阶段的执行过程中同步发起新的线程进行处理，从而使得后一个kernel的pre_kernel和前一个post_kernel运行能够重叠起来(即主机侧并行执行pre_kernel和post_kernel)。由此，整体运行时间会缩短，从而提升内核运行的效率。

在一些实施例中，使用图4中的方式二虽然能够极大地缩小集成测试覆盖率报告生成的时间，但是可能会潜在地导致设备侧动态随机存取存储器的占用量增加。例如，在后一个内核的pre_kernel阶段，前一个内核的post_kernel还没有完成，所以前一个内核的覆盖率文件缓存还不能释放，而此时后一个kernel需要动态内存分配新的覆盖率文件缓存，从而造成内存占用量相对于方式一会增加。为了缓解设备侧的本地内存(如动态随机存取存储器)占用，主机侧可以维护一个查找表，该查找表可以用于表示内核函数或任务与其对应的覆盖率文件的缓存位置之间的映射关系，从而通过更新查找表实现对设备侧内存中存储的设备侧存储的覆盖率文件的更新，从而可以实现设备侧的本地内存的空间复用，降低对设备侧存储空间的占用。

可选地，该查找表可以为键值表，该查找表可以包括多个表项，每个表项包括键(key)和相应的值(value)。其中，键(即索引项)可以是基于内核函数的标识和/或任务标识确定的，进一步地，键可以是基于内核函数和任务大小确定的。该键对应的值用于表示相应的设备侧覆盖率文件的所需的缓存位置(如缓存位置的指针)。例如，主机侧可以对每个队列维护一个基于内核函数标识(例如kernelID)和任务大小(例如taskDim)映射到设备侧覆盖率文件所需的缓存的查找表。查找表采用键值对的形式，其中，键(key)基于内核函数标识kernelID和任务大小taskDim确定，值(value)为指向设备侧覆盖率文件所需的缓存。

进一步地，主机侧可以对该查找表中的表项进行更新，从而实现设备侧内存中存储的设备侧覆盖率文件的更新。例如，主机侧可以将查找表中的至少一个表项替换为新的表项，将该被替换的表项的覆盖率文件从设备侧拷贝至主机侧，而不是将所有的设备侧覆盖文件均存储在设备侧，由此，可以缓解对设备侧动态随机存取存储器的占用情况。在一些实施例中，查找表更新遵循最近最少使用(“Least Recently Used”)原则进行更新，即当所有表项都存在有效数据时，新增表项会替换掉最久未更新的表项。另外，前文中替换出的表项对应的设备侧覆盖率文件会从设备侧内存被拷贝到主机侧，以生成对应kernelID的覆盖率文件。在其他实施例中，查找表的更新还可以遵循先进先出原则或最少使用原则等，此处不做具体限定。

需要说明的是，通过查找表对覆盖率文件查找的方式与上述按照预设的文件格式生成细粒度的覆盖率文件两种优化方式之间可择一使用。

在生成主机侧覆盖率文件和设备侧覆盖率文件之后，返回图2。在步骤S206处，对主机侧覆盖率文件进行预处理，以转换成指定格式的第一覆盖率文件。在一些实施例中，对主机侧覆盖率文件的预处理可以包括对原始数据进行加权平均，然后将预处理后的文件转换成指定格式的第一覆盖率文件。例如，可以使用llvm-profdata工具对原始数据进行加权平均，然后利用llvm-cov工具生成lcov格式的覆盖率文件。

接着，在步骤S208处，主机侧可以对设备侧覆盖率文件进行预处理，以转换成指定格式的第二覆盖率文件。

进一步地，本公开实施例还可以支持同一设备侧上多个内核函数对应的可执行文件的链接以及不同设备侧的可执行文件的链接。例如，每个设备侧支持多个内核函数，每个内核函数可以编译获得一个相应的设备侧可执行文件，设备侧链接器可以将该多个可执行文件链接生成该设备侧对应的可执行文件CNBin。其中，每个设备侧对应的可执行文件CNBin中均包含插桩代码以及插桩代码和原始设备侧代码之间的映射关系。进一步地，设备链接器还可以将不同设备侧对应的多个可执行文件CNBin链接生成CNFatbin，基于此，本公开实施例可以实现相应的多个设备侧覆盖率文件的链接，从而实现多个设备侧覆盖率文件的处理。

具体地，设备侧覆盖率文件包括多个覆盖率文件，可以分别对多个覆盖率文件中具有相同内核函数标识的覆盖率文件进行预处理。在一个实施场景中，对设备侧覆盖率文件的预处理可以包括对多个覆盖率文件中具有相同内核函数标识信息的文件进行加权平均。例如，可以使用llvm-profdata工具合并并预处理相同kernelID的文件。然后，可以使用llvm-cov工具基于预处理得到的文件生成lcov格式的覆盖率文件。

最后，在步骤S210处，可以对前述的第一覆盖文件和第二覆盖率文件进行合并处理，以生成统一覆盖率报告。例如，可以利用lcov工具将第一和第二覆盖率文件进行合并来得统一覆盖率报告。

以下结合图5对上述步骤S208～S210的具体实施过程进行详细说明。如图5所示，运行可执行文件后，可以生成主机侧覆盖率文件(如图5中host.profraw)和设备侧覆盖率文件(如图5中CNPGO_xxx)。其中，主机侧覆盖率文件具体可以通过llvm-profdata工具对原始数据进行预处理(例如加权平均处理)，以得到预处理后的文件(如图5中host.prodata)。然后使用llvm-cov工具将host.prodata生成lcov格式的第一覆盖率文件(如图5中host.info)。相对地，对于设备侧覆盖率文件处理会与此稍有不同，因为同一份代码可能会运行多个不同的内核，因此需要根据内核函数标识信息(例如kenrelID)对这些设备侧覆盖率文件分别进行处理。具体地，首先使用llvm-profdata合并并预处理相同kernelID的文件，产生如图5中的kernel1.profdata，…，kernelN.profdata。然后使用llvm-cov工具分别生成lcov格式的第二覆盖率文件(如图5中kernel1.info，…，kernelN.info)。最后阶段，使用lcov工具将第一覆盖率文件(host.prodata)和第二覆盖率文件(kernel1.info，…，kernelN.info)进行合并，生成可视化的统一覆盖率报告，也即图5中所示出的最终报告(“Final report”)。附加地或可选地，还可以对统一覆盖率报告进行可视化输出，例如可以通过图像(包括图形或图表)等多种可视化方式对覆盖率报告进行可视化展示。

基于上文的描述，本领域技术人员可以理解本申请实际上也公开了一种设备，其包括处理器和存储器。具体地，存储器可以存储用于代码覆盖率统计的程序指令，当所述程序指令由处理器执行时，实现本申请结合图1-图5所描述的方法步骤。另外，由于本申请的方案可以通过计算程序指令来实现，因此本申请也公开了一种计算机可读存储介质或计算机程序产品，其上存储有用于代码覆盖率统计的计算机程序/指令，从而实现结合图1-图5所描述的方法步骤。

以上结合附图对本公开的方案进行了详细的描述。根据不同的应用场景，本披露的设备或装置可以包括服务器、云端服务器、服务器集群、数据处理装置、机器人、电脑、打印机、扫描仪、平板电脑、智能终端、PC设备、物联网终端、移动终端、手机、行车记录仪、导航仪、传感器、摄像头、相机、摄像机、投影仪、手表、耳机、移动存储、可穿戴设备、视觉终端、自动驾驶终端、交通工具、家用电器、和/或医疗设备。所述交通工具包括飞机、轮船和/或车辆；所述家用电器包括电视、空调、微波炉、冰箱、电饭煲、加湿器、洗衣机、电灯、燃气灶、油烟机；所述医疗设备包括核磁共振仪、B超仪和/或心电图仪。本披露的设备或装置还可以被应用于互联网、物联网、数据中心、能源、交通、公共管理、制造、教育、电网、电信、金融、零售、工地、医疗等领域。

进一步，本披露的设备或装置还可以用于云端、边缘端、终端等与人工智能、大数据和/或云计算相关的应用场景中。在一个或多个实施例中，根据本披露方案的功耗高的设备或装置可以应用于云端设备(例如云端服务器)，而功耗小的设备或装置可以应用于终端设备和/或边缘端设备(例如智能手机或摄像头)。在一个或多个实施例中，云端设备的硬件信息和终端设备和/或边缘端设备的硬件信息相互兼容，从而可以根据终端设备和/或边缘端设备的硬件信息，从云端设备的硬件资源中匹配出合适的硬件资源来模拟终端设备和/或边缘端设备的硬件资源，以便完成端云一体或云边端一体的统一管理、调度和协同工作。

需要说明的是，为了简明的目的，本披露将一些方法及其实施例表述为一系列的动作及其组合，但是本领域技术人员可以理解本披露的方案并不受所描述的动作的顺序限制。因此，依据本披露的公开或教导，本领域技术人员可以理解其中的某些步骤可以采用其他顺序来执行或者同时执行。进一步，本领域技术人员可以理解本披露所描述的实施例可以视为可选实施例，即其中所涉及的动作或模块对于本披露某个或某些方案的实现并不一定是必需的。另外，根据方案的不同，本披露对一些实施例的描述也各有侧重。鉴于此，本领域技术人员可以理解本披露某个实施例中没有详述的部分，也可以参见其他实施例的相关描述。

在具体实现方面，基于本披露的公开和教导，本领域技术人员可以理解本披露所公开的若干实施例也可以通过本文未公开的其他方式来实现。例如，就前文所述的设备或装置实施例中的各个单元来说，本文在考虑了逻辑功能的基础上对其进行划分，而实际实现时也可以有另外的划分方式。又例如，可以将多个单元或组件结合或者集成到另一个系统，或者对单元或组件中的一些特征或功能进行选择性地禁用。就不同单元或组件之间的连接关系而言，前文结合附图所讨论的连接可以是单元或组件之间的直接或间接耦合。在一些场景中，前述的直接或间接耦合涉及利用接口的通信连接，其中通信接口可以支持电性、光学、声学、磁性或其它形式的信号传输。

在本披露中，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元示出的部件可以是或者也可以不是物理单元。前述部件或单元可以位于同一位置或者分布到多个网络单元上。另外，根据实际的需要，可以选择其中的部分或者全部单元来实现本披露实施例所述方案的目的。另外，在一些场景中，本披露实施例中的多个单元可以集成于一个单元中或者各个单元物理上单独存在。

在一些实现场景中，上述集成的单元可以采用软件程序模块的形式来实现。如果以软件程序模块的形式实现并作为独立的产品销售或使用时，所述集成的单元可以存储在计算机可读取存储器中。基于此，当本披露的方案以软件产品(例如计算机可读存储介质)的形式体现时，该软件产品可以存储在存储器中，其可以包括若干指令用以使得计算机设备(例如个人计算机、服务器或者网络设备等)执行本披露实施例所述方法的部分或全部步骤。前述的存储器可以包括但不限于U盘、闪存盘、只读存储器(“Read Only Memory”，简写为ROM)、随机存取存储器(“Random Access Memory”，简写为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

在另外一些实现场景中，上述集成的单元也可以采用硬件的形式实现，即为具体的硬件电路，其可以包括数字电路和/或模拟电路等。电路的硬件结构的物理实现可以包括但不限于物理器件，而物理器件可以包括但不限于晶体管或忆阻器等器件。鉴于此，本文所述的各类装置(例如计算装置或其他处理装置)可以通过适当的硬件处理器来实现，例如CPU、GPU、FPGA、DSP和ASIC等。进一步，前述的所述存储单元或存储装置可以是任意适当的存储介质(包括磁存储介质或磁光存储介质等)，其例如可以是可变电阻式存储器(“Resistive Random Access Memory”，简写为RRAM)、动态随机存取存储器(“DynamicRandom Access Memory”，简写为DRAM)、静态随机存取存储器(“Static Random AccessMemory”，简写为SRAM)、增强动态随机存取存储器(“Enhanced Dynamic Random AccessMemory”，简写为“EDRAM”)、高带宽存储器(“High Bandwidth Memory”，简写为“HBM”)、混合存储器立方体(“Hybrid Memory Cube”，简写为“HMC”)、ROM和RAM等。

依据以下条款可更好地理解前述内容：

条款A1、一种代码覆盖率统计的方法，其中所述代码包括主机侧代码和设备侧代码，所述方法包括：

分别对所述主机侧代码和所述设备侧代码执行插桩和编译操作，以得到可执行文件，其中，所述主机侧代码和所述设备侧代码包含用于获得覆盖率信息的插桩代码，所述可执行文件能够在包含主机侧和设备侧的异构计算平台上运行；

根据所述可执行文件的运行结果，生成主机侧覆盖率文件和设备侧覆盖率文件；以及

基于所述主机侧覆盖率文件和所述设备侧覆盖率文件生成统一覆盖率报告。

条款A2、根据条款A1所述的方法，其中所述方法还包括:

利用预设编译选项分别对所述主机侧代码和所述设备侧代码执行插桩操作，以获得所述包含插桩代码的主机侧代码和设备侧代码；

分别生成所述插桩代码与原始主机侧代码、原始设备侧代码之间的映射关系。

条款A3、根据条款A2所述的方法，其中所述设备侧代码包括内核函数，并且对所述设备侧代码执行插桩和编译操作包括：

仅针对所述内核函数执行插桩和编译操作。

条款A4、根据条款A1-A3中任一项所述的方法，其中所述方法包括：

依照预设的文件格式生成所述设备侧覆盖率文件。

条款A5、根据条款A4所述的方法，其中所述设备侧代码包括一个或多个内核函数，所述设备侧覆盖率文件的缓存放置在设备侧的本地内存中，所述方法还包括：

响应于每个所述内核函数运行结束，将所述本地内存中的所述设备侧覆盖率文件的缓存复制至主机侧；以及

基于所述主机侧中的所述设备侧覆盖率文件的缓存，生成所述设备侧覆盖率文件。

条款A6、根据条款A1-A3中任一项所述的方法，其中所述设备侧代码包括一个或多个内核函数，每个所述内核函数的运行过程包括主机侧的数据准备阶段、设备侧的内核运行阶段和主机侧的数据回传阶段，所述方法还包括：

响应于任一所述内核函数对应的数据回传阶段完成后，启动下一所述内核函数的数据准备阶段，其中任一所述内核函数和下一所述内核函数属于同一队列，且属于同一内核或不同内核。

条款A7、根据条款A1-A3中任一项所述的方法，其中所述设备侧代码包括一个或多个内核函数，每个所述内核函数的运行过程包括主机侧的数据准备阶段、设备侧的内核运行阶段和主机侧的数据回传阶段，所述方法还包括：

在任一所述内核函数对应的数据回传阶段执行过程中，同步启动与下一所述内核函数的数据准备阶段，其中任一所述内核函数和下一所述内核函数属于同一队列，且属于同一内核或不同内核。

条款A8、根据条款A1-A3中任一项所述的方法，其中所述设备侧代码包括一个或多个设备内核，所述方法还包括：

维护并更新查找表，所述查找表用于表示所述设备内核与相应的设备侧覆盖率文件的缓存位置的映射关系。

条款A9、根据条款A8所述的方法，其中所述查找表为键值表，所述查找表中的键基于设备内核的标识确定；所述查找表中的值指向所述设备侧覆盖率文件的缓存位置。

条款A10、根据条款A9所述的方法，其中所述更新查找表包括：

根据最近最少使用原则更新所述查找表。

条款A11、根据条款A5所述的方法，所述方法还包括：

计算内核函数的设备侧覆盖率文件所需的缓存大小；以及

将所述缓存大小记录在所述内核函数的配置项中，以在设备侧运行所述内核函数时，根据计算得到的设备侧覆盖率文件的缓存大小进行自适应缓存分配。

条款A12、根据条款A1或A2所述的方法，所述方法还包括：

对所述主机侧覆盖率文件进行预处理，以转换成指定格式的第一覆盖率文件；

对所述设备侧覆盖率文件进行预处理，以转换成所述指定格式的第二覆盖率文件；以及

对所述第一覆盖文件和所述第二覆盖率文件进行合并处理，以生成所述统一覆盖率报告。

条款A13、根据条款A12所述的方法，其中所述设备侧覆盖率文件包括多个覆盖率文件，其中对所述设备侧覆盖率文件进行预处理包括：

分别对所述多个覆盖率文件中具有相同内核函数标识的覆盖率文件进行预处理。

条款A14、根据条款A12所述的方法，还包括：

对所述统一覆盖率报告进行可视化输出。

条款A15、一种代码覆盖率统计的设备，包括：

处理器；以及

存储器，其存储有代码覆盖率统计的程序指令，当所述计算机可执行指令由所述一个或多个处理器运行时，使得所述设备执行根据条款A1-A14的任意一项所述的方法。

条款A16、一种板卡，包括：

一个或多个处理芯片，其中每个处理芯片包括一个或多个处理核；

控制器件；以及

驱动程序，其运行于控制器件中并且包括软件调度器，其中当所述驱动程序由控制器件控制运行时，使得所述软件调度器执行根据条款A1-A14的任意一项所述的方法，以便将每个任务流中的任务下发至所述处理芯片。

条款A17、一种计算机可读存储介质，其存储有代码覆盖率统计的计算机指令，当所述计算机指令由一个或多个处理器运行时，执行根据条款A1-A14的任意一项所述的方法。

虽然本公开的实施方式如上，但所述内容只是为便于理解本公开而采用的实施例，并非用以限定本公开的范围和应用场景。任何本公开所述技术领域内的技术人员，在不脱离本公开所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本公开的专利保护范围，仍须以所附的权利要求书所界定的范围为准。

Claims (15)

1.一种代码覆盖率统计的方法，其中所述代码包括主机侧代码和设备侧代码，所述方法包括：

分别对所述主机侧代码和所述设备侧代码执行插桩和编译操作，以得到可执行文件，其中，所述主机侧代码和所述设备侧代码包含用于获得覆盖率信息的插桩代码，所述可执行文件能够在包含主机侧和设备侧的异构计算平台上运行；

根据所述可执行文件的运行结果，生成主机侧覆盖率文件和设备侧覆盖率文件；以及

基于所述主机侧覆盖率文件和所述设备侧覆盖率文件生成统一覆盖率报告。

2.根据权利要求1所述的方法，其中所述方法包括:

利用预设编译选项分别对所述主机侧代码和所述设备侧代码执行插桩操作，以获得所述包含插桩代码的主机侧代码和设备侧代码；

分别生成所述插桩代码与原始主机侧代码、原始设备侧代码之间的映射关系。

3.根据权利要求1所述的方法，其中所述方法还包括：

依照预设文件格式生成所述设备侧覆盖率文件。

4.根据权利要求1或2所述的方法，其中所述设备侧代码包括一个或多个内核函数，所述设备侧覆盖率文件的缓存放置在设备侧的本地内存中，所述方法还包括：

响应于每个所述内核函数运行结束，将所述本地内存中的所述设备侧覆盖率文件的缓存复制至主机侧；以及

基于所述主机侧中的所述设备侧覆盖率文件的缓存，生成所述设备侧覆盖率文件。

5.根据权利要求1或2所述的方法，其中所述设备侧代码包括一个或多个内核函数，每个所述内核函数的运行过程包括主机侧的数据准备阶段、设备侧的内核运行阶段和主机侧的数据回传阶段，所述方法还包括：

响应于任一所述内核函数对应的数据回传阶段完成后，启动下一所述内核函数的数据准备阶段，其中任一所述内核函数和下一所述内核函数属于同一队列，且属于同一内核或不同内核。

6.根据权利要求1或2所述的方法，其中所述设备侧代码包括一个或多个内核函数，每个所述内核函数的运行过程包括主机侧的数据准备阶段、设备侧的内核运行阶段和主机侧的数据回传阶段，所述方法还包括：

在任一所述内核函数对应的数据回传阶段执行过程中，同步启动与下一所述内核函数的数据准备阶段，其中任一所述内核函数和下一所述内核函数属于同一队列，且属于同一内核或不同内核。

7.根据权利要求1或2所述的方法，其中所述设备侧代码包括一个或多个内核函数，所述方法还包括：

维护并更新查找表，所述查找表用于表示所述内核函数与相应的设备侧覆盖率文件的缓存位置的映射关系。

8.根据权利要求7所述的方法，其中所述查找表为键值表，所述查找表中的键基于内核函数的标识确定；所述查找表中的值指向所述设备侧覆盖率文件的缓存位置。

9.根据权利要求7所述的方法，其中所述更新查找表包括：

根据最近最少使用原则更新所述查找表。

10.根据权利要求1或2所述的方法，所述方法还包括：

计算内核函数的设备侧覆盖率文件所需的缓存大小；以及

将所述缓存大小记录在所述内核函数的配置项中，以在设备侧运行所述内核函数时，根据计算得到的设备侧覆盖率文件的缓存大小进行自适应缓存分配。

11.根据权利要求1或2所述的方法，所述方法还包括：

对所述主机侧覆盖率文件进行预处理，以转换成指定格式的第一覆盖率文件；

对所述设备侧覆盖率文件进行预处理，以转换成所述指定格式的第二覆盖率文件；以及

对所述第一覆盖文件和所述第二覆盖率文件进行合并处理，以生成所述统一覆盖率报告。

12.根据权利要求11所述的方法，其中所述设备侧覆盖率文件包括多个覆盖率文件，其中对所述设备侧覆盖率文件进行预处理包括：

分别对所述多个覆盖率文件中具有相同内核函数标识的覆盖率文件进行预处理。

13.根据权利要求11所述的方法，还包括：

对所述统一覆盖率报告进行可视化输出。

14.一种代码覆盖率统计的设备，包括：

一个或多个处理器；以及

存储器，所述存储器中存储有覆盖率统计的计算机可执行指令，当所述计算机可执行指令由所述一个或多个处理器运行时，使得所述设备执行如权利要求1-13中任意一项所述的方法。

15.一种计算机可读存储介质，包括覆盖率统计的计算机指令，当所述计算机指令由一个或多个处理器运行时，执行如权利要求1-13中任意一项所述的方法。