0HAL Id: tel-029084980https://theses.hal.science/tel-029084980提交日期：2020年7月29日0HAL是一个多学科的开放获取档案，用于存储和传播科学研究文献，无论其是否发表。这些文献可以来自法国或国外的教育和研究机构，或者来自公共或私人研究中心。0HAL多学科开放获取档案，用于存储和传播研究级科学文献，无论其是否发表，来自法国或国外的教育和研究机构，公共或私人实验室。0二进制文件性能调试工具箱：敏感性分析和依赖性分析0Fabian Gruber0引用此版本：0Fabian Gruber. 二进制文件性能调试工具箱：敏感性分析和依赖性分析. 数学软件[cs.MS].格勒诺布尔阿尔卑斯大学, 2019. 英文. �NNT: 2019GREAM071�. �tel-02908498�0博士论文0获得学位：0格勒诺布尔阿尔卑斯大学博士0专业：计算机科学0部长令：2016年5月25日0由FabianGRUBER提出0由Fabrice RASTELLO指导的博士论文0在格勒诺布尔计算机实验室内准备，在数学、科学和信息技术学院的博士学位论文0二进制代码性能调试：敏感性分析和依赖性分析0二进制文件性能调试工具箱：敏感性分析和依赖性分析0于2019年12月17日公开支持，评审委员会成员：0FABRICE RASTELLO先生，INRIA GRENOBLERHÔNE-ALPES研究主任，导师BARTONMILLER教授，威斯康星大学麦迪逊分校-美国，评审员DENISBARTHOU教授，波尔多国立理工学院，评审员FRANZFRANCHETTI教授，卡内基梅隆大学-美国，考官FREDERICPETROT教授，格勒诺布尔国立理工学院，主席SVILENKANEV博士工程师，谷歌-美国，考官0iii0摘要0调试通常是指查找和消除阻止软件正常运行的问题。因此，当我们谈论错误和调试时，通常指的是功能错误和功能调试。然而，在本论文的背景下，我们将讨论性能错误和性能调试。因此，我们不是寻找导致程序出现错误行为的问题，而是寻找使其低效、过慢或过度使用资源的问题。为此，我们开发了分析和建模性能的工具，以帮助程序员从这个角度改进他们的代码。我们提出了以下两种性能调试技术：基于敏感性的瓶颈分析和基于数据依赖的多面体优化建议。0基于敏感性的瓶颈分析对于回答一个看似无关紧要的关于程序性能的问题可能会非常困难，比如判断程序是受内存还是受CPU限制。实际上，CPU和内存并不是完全独立的两个资源，而是由多个复杂且相互依赖的子系统组成。在这里，一个资源的阻塞可能同时掩盖或加剧另一个资源的问题。我们提出了一种基于敏感性的瓶颈分析方法，该方法使用在Gus中实现的高级性能模型来快速识别性能瓶颈。我们的性能模型需要一个基准来衡量CPU上不同操作的预期性能，比如IPC峰值和不同指令如何共享处理器资源。不幸的是，这些信息很少由硬件供应商（如Intel或AMD）公开发布。为了构建我们的处理器模型，我们开发了一个系统，使用自动生成的微基准来获取所需的信息。0基于数据依赖的多面体优化反馈我们开发了Mickey，一个动态数据依赖分析器，它提供了关于编译器未能优化的优化的适用性和盈利能力的高级反馈。Mickey利用多面体模型，这是一个强大的优化框架，用于找到一系列循环转换以暴露数据局部性并实现粗粒度（线程级别）和细粒度（向量级别）的并行性。我们的工具使用动态二进制插装来分析使用不同编程语言编写的程序或使用没有源代码的第三方库的程序。在内部，Mickey使用多面体中间表示（IR），它编码了程序指令的动态执行以及其数据依赖关系。IR不仅捕捉多个循环之间的数据依赖关系，还捕捉跨过程调用（可能是递归的）的数据依赖关系。我们开发了一种高效的跟踪压缩算法，称为折叠算法，它从程序的执行中构建这个多面体IR。折叠算法还可以找到内存访问中的步长，以预测向量化的可能性和盈利能力。它可以通过安全、选择性的过度逼近机制来扩展到实际应用中的部分不规则数据依赖和迭代空间。0iv0v0摘要0调试，通常理解的是围绕着找到并消除软件中阻止其正常运行的缺陷。也就是说，当谈论错误和调试时，通常是指功能性错误和功能性调试。然而，在本论文的背景下，我们将谈论性能错误和性能调试。这意味着我们要找到不会导致程序崩溃或行为错误，但会使其运行效率低下、过慢或使用过多资源的缺陷。为此，我们开发了分析和建模性能的工具，以帮助程序员改进他们的代码以获得更好的性能。我们提出了以下两种性能调试技术：基于敏感性的瓶颈分析和基于数据依赖的优化反馈。0基于敏感性的性能瓶颈分析回答一个看似微不足道的关于程序性能的问题，比如它是内存受限还是CPU受限，可能会出乎意料地困难。这是因为CPU和内存不仅仅是两个完全独立的资源，而是由多个复杂的相互依赖的子系统组成。在这里，一个资源的停顿既可以掩盖另一个资源的问题，也可以加剧另一个资源的问题。我们提出了一种基于敏感性的性能瓶颈分析方法，它使用在Gus中实现的高级性能模型来定位性能瓶颈。我们的性能模型需要一个CPU上不同操作的预期性能的基准，比如峰值IPC以及不同指令之间如何竞争处理器资源。不幸的是，这些信息很少由硬件供应商（如Intel或AMD）发布。为了构建我们的处理器模型，我们开发了一个系统，使用自动生成的微基准来逆向工程所需的信息。0基于数据依赖的多面体优化反馈我们开发了Mickey，一个动态数据依赖分析器，它提供了关于编译器未能优化的优化的适用性和盈利能力的高级反馈。Mickey利用多面体模型，这是一个强大的优化框架，用于找到一系列循环转换以暴露数据局部性并实现粗粒度（线程级别）和细粒度（向量级别）的并行性。我们的工具使用动态二进制插装来分析使用不同编程语言编写的程序或使用没有源代码的第三方库的程序。在内部，Mickey使用多面体中间表示（IR），它编码了程序指令的动态执行以及其数据依赖关系。IR不仅捕捉多个循环之间的数据依赖关系，还捕捉跨过程调用（可能是递归的）的数据依赖关系。我们开发了一种高效的跟踪压缩算法，称为折叠算法，它从程序的执行中构建这个多面体IR。折叠算法还可以找到内存访问中的步长，以预测向量化的可能性和盈利能力。它可以通过安全、选择性的过度逼近机制来扩展到实际应用中的部分不规则数据依赖和迭代空间。viDedicationThis thesis is dedicated to my future wife Kim Hyunyoung, my family, and my friends.Thank you from the bottom of my heart.viiviiiAcknowledgementsThe work presented in this thesis has been done in collaboration with my advisor FabriceRastello, Louis-Noël Pouchet from the Colorado State University, Christophe Guillon and othersfrom STMicroelectronics, my colleagues Diogo Nunes Sampaio, Manuel Selva, Nicolas Tollenare,Nicolas Derumigny, and many more.I sincerely thank them all for their advice, help, and hard work.Without them my thesis would not have been possible.I also sincerely thank Imma Presseguer for all the administrative work, moral support andadvice.ixxContentsRésuméiiiAbstractvContentsxi1Introduction11.1Performance Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.1Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.2Instrumentation and dynamic binary analysis . . . . . . . . . . . . . . . .51.2.3The polyhedral model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61.3Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81.3.1Sensitivity Based Performance Bottleneck Analysis . . . . . . . . . . . . .81.3.2Dependence Profiling Driven Polyhedral Optimization Feedback. . . . .91.3.3Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101.4Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1033.4.1A resource-centric CPU model. . . . . . . . . . . . . . . . . . . . . . . .493.4.2An illustrative example. . . . . . . . . . . . . . . . . . . . . . . . . . . .503.4.3The simulator algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . .543.5Pipedream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56xi02 使用QEMU进行动态二进制插装 1102.2 微型代码生成器 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1302.4 使用QEMU进行执行跟踪 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1902.4.2 数据依赖跟踪 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2702.5 插件开销评估 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2802.7 结论与展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3403.1 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3603.2.1 指令级并行概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3803.3 相关工作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41xiiCONTENTS3.5.1The instruction flow problem . . . . . . . . . . . . . . . . . . . . . . . . .573.5.2Finding port mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . .613.5.3Converting port mappings to resource models . . . . . . . . . . . . . . . .653.5.4Benchmark design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .663.6Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .693.6.1Gus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .693.6.2Pipedream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783.7Conclusion and Future Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . .854Data-Dependence Driven Optimization Feedback894.1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .904.2Illustrative Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .914.2.1Example problem: backprop . . . . . . . . . . . . . . . . . . . . . . . . . .914.2.2Solution: Mickey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .934.3Overview of Mickey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .944.4Interprocedural Program Representation . . . . . . . . . . . . . . . . . . . . . . .964.4.1Control-flow-graph and loop-nesting-tree . . . . . . . . . . . . . . . . . . .974.4.2Call-graph and recursive-component-set . . . . . . . . . . . . . . . . . . .984.8Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1344.9Conclusion and Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138List of Figures144List of Algorithms14704.5 折叠算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.5.1 输入 . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 10604.5.3 使用输出 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10904.5.5 算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11104.6 多面体反馈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.6.1 折叠数据依赖图的多面体编译 . .. . . . . . . . . . . . . . . . . 12204.7 实验结果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 4.7.1 案例研究 . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 12804.7.3 Rodinia上的优化反馈 . . . . . . . . . . . . . . . . . . . . . . 13105 结论与未来工作 13905.1.1 使用QEMU的动态二进制仪器化 . . . . . . . . . . . . . . . . . . . . . . . . . . 14005.1.3 数据依赖驱动的优化反馈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14105.3 发表论文列表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1430表格列表 146Bibliography1490目录 xiii0术语表 167xivCONTENTSIntroduction1.1Performance Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.1Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31.2.3The polyhedral model. . . . . . . . . . . . . . . . . . . . . . . . . . .61.3.1Sensitivity Based Performance Bottleneck Analysis . . . . . . . . . . .81.3.3Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1010第 1 章0目录01.2 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.2.2 仪器化和动态二进制分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501.3 目标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801.3.2 依赖分析驱动的多面体优化反馈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901.4 论文结构 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102CHAPTER 1. INTRODUCTION197019801990200020102020Year1001011021031041051060距离HerbSutter撰写他著名文章“免费午餐结束”已经将近15年了[201]。在这篇文章中，他认为提升单核性能的经典方法，如提高CPU时钟频率和直线指令吞吐量，已经不再可行。他声称现代微处理器的单核性能完全停滞不前，多核架构和并发编程模型是提高性能的唯一途径。仅仅几年后，Hill等人[94]分析了当时微处理器设计的状态，并提出了一些广泛的建议，至少在某种程度上与Sutter的结论相矛盾。他们的建议之一是“研究人员应该寻求以高成本提高[单个]核心性能的方法”。图1.1显示了描述过去42年微处理器性能参数整体趋势的数据。从数据来看，两种预测似乎在某种程度上都被证明是正确的。时钟频率完全停滞不前，而处理器的平均核心数却激增。然而，处理器的单核性能，如SpecINT [91,92]基准套件所测量的，仍在不断提高。尽管增长速度比过去慢了，但我们可以推断出，由于时钟频率没有提高，性能的增加确实是以硬件和软件复杂性的增加为代价的。010 7 个晶体管（千个）0单线程性能（SpecINT x 10 3 ） 频率（Mhz）典型功耗（瓦特） 逻辑核心数0图1.1 - 42年的微处理器趋势[176]0在日常编程中，这种复杂性的增加通常被抽象隐藏起来。例如，现代的x86处理器在许多方面仍然假装与上世纪80年代的模型工作方式相似。也就是说，对于程序员来说，指令似乎是按顺序执行的，并且每个加载和存储直接与主内存交互。然而，在底层，现代CPU是一个复杂的并行系统，具有深层次的内存层次结构和缓存。然而，当我们想要研究和理解应用程序的性能时，所有这些抽象很快就会崩溃。因此，了解哪些数据依赖关系阻止了两个指令的并行执行，或者哪个内存访问导致了缓存未命中，变得至关重要。为了有效地分析和调试程序的性能，必须深入了解并消除这些抽象。本论文的目标是提出工具和技术，帮助程序员更好地理解其程序的行为，并指导他们进行性能优化的过程。Debugging, as usually understood, revolves around finding and removing defects in software thatprevent it from functioning correctly. That is, when one talks about bugs and debugging oneusually means functional bugs and functional debugging. In the context of this thesis, however,we will talk about performance bugs and performance debugging. Meaning we want to find defectsthat do not cause a program to crash or behave wrongly, but that make it run inefficiently, tooslow, or use too many resources.Even the best programmer has, at some point, written a buggy program. When they observethat something is amiss they will often use functional debugging tools like GDB [74] that helpfind errors in the behaviour of programs. That is, the classical problems for which programmersturn to functional debuggers are:01.1. 性能调试 30通常情况下，调试是指查找和消除软件中阻止其正确运行的缺陷。也就是说，当谈到错误和调试时，通常指的是功能性错误和功能性调试。然而，在本论文的背景下，我们将讨论性能错误和性能调试。这意味着我们要找到不会导致程序崩溃或行为错误，但会使其运行效率低下、速度过慢或使用过多资源的缺陷。即使是最好的程序员，也可能在某个时候编写出有缺陷的程序。当他们观察到有问题时，他们通常会使用像GDB[74]这样的功能性调试工具来帮助找到程序行为中的错误。也就是说，程序员使用功能性调试器的经典问题有：01.1 性能调试01. 程序在哪里出现问题或崩溃？2.程序为什么出现问题或崩溃？通常，这些工具不直接试图回答如何防止程序出现问题或崩溃的问题，因为这需要改变程序的语义。虽然有一些从软件验证领域尝试这样做的方法，比如运行时强制执行[69]，但它们需要对程序的预期语义进行规范，并且尚未被广泛使用。另一方面，性能调试器或性能分析工具有助于找到程序的非功能性问题。也就是说，程序员使用这些工具的原因是解决以下问题：01. 程序在哪里运行缓慢？2. 程序为什么运行缓慢？3.如何使程序运行更快？从历史上看，现有的技术只能测量和预测程序的当前性能特征，因此与功能性调试工具类似，只能帮助回答前两个问题。在本论文中，我们将开发两种方法，试图推断系统可能实现的性能，以帮助回答后两个问题，即为什么程序运行缓慢以及如何使其更高效。01.2 背景01.2.1 性能分析0识别性能错误的标准方法是进行性能分析。最直接的性能分析技术是测量运行一段代码所需的时间。像gprof[78]这样的工具通过自动插入代码来测量编译器中每个函数的运行时间，从而自动化这个过程。其他工具如QPT[122]插入代码来计算程序中每个基本块执行的次数，或者控制流图中每个边被执行的次数。这些方法可以帮助检测热点程序区域，即程序的运行速度较慢的地方。0第1章 引言0大多数时间都花在了程序的热点区域。然而，仅仅知道程序的热点区域往往不足以修复性能错误。为了帮助定位性能问题的原因，现代处理器提供了硬件性能计数器[44,151]，也称为硬件计数器或性能计数器。硬件计数器允许测量许多不同的与性能相关的事件，例如执行的指令数、不同缓存级别的缓存命中和缓存失效次数等。在最基本的层面上，性能计数器的工作方式与时间测量相同。例如，要测量在给定函数中发生的L2缓存失效次数，只需在函数的开头和结尾插入代码来读取相应计数器的当前值，并将两个值相减。许多处理器还支持采样模式，可以在不修改应用程序以显式读取计数器的情况下使用硬件计数器。不同的供应商和处理器代数实现了各种不同的采样模型，例如基于事件的采样、时间采样和基于指令的采样。这些不同采样技术的工作细节、使用方法和精度差异很大。然而，总体思想是，在定期的用户配置间隔内，处理器停止正常执行，并存储硬件性能计数器的当前值，通常是通过将一些数据写入预配置的内存位置或引发特殊中断来实现。基于采样的分析器然后使用统计方法来推断它们没有样本的指令的行为。直接使用硬件性能计数器非常复杂，因此随着时间的推移，已经开发出了大量用于此目的的库和工具，例如PAPI [65]，LIKWID [172]，HPCToolkit [4]，Linux perf[144]，Intel VTune[169]。尽管硬件性能计数器非常有用，但也存在一些严重的限制。虽然配置CPU计数性能事件几乎没有任何开销，但直接读取计数器或通过采样读取计数器并不是免费的。直接读取计数器会使用至少一些CPU资源，例如寄存器，而分析需要昂贵的CPU中断或一些写入内存的操作。因此，使用硬件计数器可能会导致观察者效应，即测量应用程序性能的行为会改变其性能。这可能导致所谓的性能Heisenbugs，以Heisenberg的不确定性原理命名。它还使得使用性能计数器进行细粒度的分析变得困难。例如，广泛使用的基于采样的分析工具Linuxperf默认限制了最大采样率。这是为了防止程序意外地花费更多的时间读取性能计数器和写入内部缓冲区，而不是实际执行真正的代码。在运行频率为3.3 GHz的Intel i5-4590CPU上，限制是每秒50k个样本，这意味着最多可以每66k个指令获得一个样本。性能计数器的另一个问题是只能测量一组固定的指标。采用这种方法，无法为硬件不提供计数器的事件进行分析。此外，即使在最新的处理器上，也不能同时启用所有可用的性能事件计数器，通常只能启用四到十个。使用硬件性能计数器的替代方法是使用模拟器，例如gem5[23]。一个周期精确的模拟器可以在不干扰原始程序行为的情况下生成性能相关事件的详细跟踪。由于模拟器是软件，如果需要，还可以添加新的性能计数器。然而，模拟器的强大和灵活性也是有代价的。开发一个周期级的模拟器非常耗时，并且需要很多专业知识。详细的模拟在计算方面也相当昂贵，并且运行速度比本机执行要慢得多。例如，gem5在其最高精度级别上平均需要一年才能运行一次。0术语“计数器”可能会引起误解，因为现代处理器不仅仅是计数事件。01.2. 背景 50SPEC2006基准测试[180]。加速模拟的常见方法是只模拟程序的部分部分[188,224]或只模拟处理器的某些方面[36, 110,152]。基于抽象高级CPU核心模型的模拟器虽然不如真实的周期级模拟器准确，但已经证明在运行速度比周期级模拟系统快几个数量级的同时，提供了合理准确的执行时间预测[68, 76, 202,37]。使用硬件计数器或模拟进行的性能分析收集的数据仍然是非常低级的，记录了每条机器指令的信息。像HPCToolkit [4]、Intel VTune [169]和Linux perf[144]这样的工具可以使用调试信息将这些结果映射回程序的源代码，从而可以查看每个循环或函数的聚合结果。然而，这些工具仍然不能直接解释为什么给定的代码存在性能问题，比如缓存失效或CPU周期停顿过多，也不能解释如何解决问题。找到和解决性能问题的根本原因通常仍然需要相当的专业知识。0反馈导向优化（FDO）朝着使用性能分析信息来提高性能的方向迈出了一步[192, 11,12]。基于FDO的系统使用分析来收集运行时信息，并将其用于指导编译器中的优化启发式算法。另一方面，像Intel Advisor [52]和AutoSCOPE[195]这样的工具试图提供可读性强的优化建议。然而，它们无法自动应用代码转换，甚至不能证明转换是有效的。相反，它们提出了一些优化，如并行化或循环融合，将实现这些转换的任务留给程序员。到目前为止，我们只是简要介绍了基本的性能分析技术。第3章将更详细地介绍这些技术。0第4章将介绍一些更复杂的方法，使用更丰富但更昂贵的性能事件。01.2.2 仪器和动态二进制分析0由于分析器分析程序执行过程中发生的事件，因此它们需要一些跟踪这些事件的工具。硬件性能计数器的采样是一种非常低开销的收集性能相关事件的方法，但它存在一些限制，如前一节所述。大量动态分析工具（包括本论文中介绍的工具）使用的另一种技术是仪器化。仪器化是一种非常灵活的技术，可以捕获任意的程序行为。使用仪器化，分析器可以在软件中实现任何新的性能计数器。除了性能分析，仪器化还用于许多其他动态分析，如动态控制流完整性[1]和内存损坏检查[185]。有一些新的硬件辅助程序跟踪技术，如Intel PT[51]，可能会取代某些性能分析用例中的仪器化。然而，目前可用的硬件仍然有些不可靠，并且可能由于内部缓冲区溢出而丢失事件[75, 101]。高度成功的动态分析工具（如gprof [78]和LLVM AddressSanitizer[185]）使用的基于编译器的仪器化直接在编译器中工作，工作在其中间表示（IR）的级别上。在编译过程中仪器化程序具有几个优点。就生产力而言，整个编译器基础设施使得为性能分析实现一些仪器化变得容易。仪器化可以在任何中间表示的级别上轻松执行，允许对高级和低级属性进行性能分析。它还可以利用编译器中的各种静态分析提供的程序语义和信息。特别是，任何可以静态证明或不依赖数据的属性都不需要进行仪器化。
我的内容管理
展开
