LLVM Link Time Optimizer 链接时优化图例

Posted 2023-06-01 吴建明

LLVM Link Time Optimizer 链接时优化图例

 

 

 

 

 

 

 

参考文献链接

https://blog.csdn.net/dashuniuniu/article/details/122769486?spm=1001.2014.3001.5502

人工智能芯片与自动驾驶

编译器:gcc, clang, llvm

clang

Clang是LLVM的前端，可以用来编译C，C++，ObjectiveC等语言。传统的编译器通常分为三个部分，前端(frontEnd)，优化器(Optimizer)和后端(backEnd)。在编译过程中，前端主要负责词法和语法分析，将源代码转化为抽象语法树；优化器则是在前端的基础上，对得到的中间代码进行优化，使代码更加高效；后端则是将已经优化的中间代码转化为针对各自平台的机器代码。Clang则是以LLVM为后端的一款高效易用，并且与IDE结合很好的编译前端。

llvm

LLVM的命名最早来源于底层语言虚拟机（Low Level Virtual Machine）的缩写。它是一个用于建立编译器的基础框架，以C++编写。创建此工程的目的是对于任意的编程语言，利用该基础框架，构建一个包括编译时、链接时、执行时等的语言执行器。目前官方的LLVM只支持处理C/C++，Objective-C三种语言，当然也有一些非官方的扩展，使其支持ActionScript、Ada、D语言、Fortran、GLSL、Haskell、Java bytecode、Objective-C、Python、Ruby、Rust、Scala以及C#。

为何llvm/clang可以发展起来

1. LLVM / Clang License是BSD，这条很重要

2. GCC代码搓，历史包袱巨重，而LLVM / Clang 代码组织结构非常漂亮，你想要改LLVM / Clang 比 GCC 轻松很多。最近我给GCC和Clang都开过Bug，但是Clang的Bug我都愿意去找源码哪里可以修改，报Bug的时候也会说我找到的地方，如何修改等（如Bug 23791 – Clang emit wrong mangling of long double type for PPC64 in the Red Hat），但是GCC我都不愿意去看源代码（虽然我也不能看），只报Bug。

3. LLVM / Clang 自己的表现也确实很出色，编译速度，执行速度，诊断信息等4. LLVM / Clang 的背后是有钱的苹果，有钱真的是大爷而背后的动力和推手么，动力就是对GCC用的很不满，定制性，可扩展性等都非常的差，而且那时候苹果的Objective-C在GCC那里也得不到很好的支持。这里再次说了License，就说说License这条到底有多重要。比如我们IBM编译器其实除了我所在IBM XL C/C++ Compiler，我们还有一个组是与GCC有关联的，叫做Advance Toolchain，简称AT，而AT Team的就是专干GCC的，而在那个组干过的人就永不能到我们这边干活。同样，由于License的原因，我们根本不准看GCC代码，只能猜，但是我们却又要保持与它的兼容性，那么有了BSD License那可就爽多了。而你说其它开源的东西，如Linux等再造。其它开源的东西姑且不说，如果是类似Linux这样的东西造起来，那么先说一下新造出来的操作系统的生态问题吧。即为什么要用你这个操作系统，还要为你这个操作系统开发软件呢？

Clang和LLVM的关系

Clang和LLVM到底是什么关系，这是在研究Clang的过程中所不可避免的一个问题。如果要搞清楚Clang和LLVM之间的关系，首先先要知道宏观的LLVM和微观的LLVM。

宏观的LLVM，指的是整个的LLVM的框架，它肯定包含了Clang，因为Clang是LLVM的框架的一部分，是它的一个C/C++的前端。虽然这个前端占的比重比较大，但是它依然只是个前端，LLVM框架可以有很多个前端和很多个后端，只要你想继续扩展。

微观的LLVM指的是以实际开发过程中，包括实际使用过程中，划分出来的LLVM。比如编译LLVM和Clang的时候，LLVM的源码包是不包含Clang的源码包的，需要单独下载Clang的源码包。

所以这里想讨论的就是微观的LLVM和Clang的关系。从编译器用户的角度，Clang使用了LLVM中的一些功能，目前所知道的主要就是对中间格式代码的优化，或许还有一部分生成代码的功能。从Clang和微观LLVM的源码位置可以看出，Clang是基于微观的LLVM的一个工具。而从功能的角度来说，微观的LLVM可以认为是一个编译器的后端，而Clang是一个编译器的前端，它们的关系就更加的明了了，一个编译器前端想要程序最终变成可执行文件，是缺少不了对编译器后端的介绍的。

这样基本就确定了Clang和LLVM的关系。这个问题虽然并不复杂，但是对于后续的结构理解和深入研究确是一个很重要的出发点。这个出发点不理清楚的话，后续的研究没有办法继续深入下去。

Clang的整体架构

如果要深入的研究Clang，那么首先需要知道Clang的整体架构。直接打开Clang的源码的话，里面目录较多，无从下手。可以直接从doxygen文档看，Clang的doxygen的地址是：http://clang.llvm.org/doxygen/index.html 。从这个首页选取Directories，可以直接进到文件目录列表：http://clang.llvm.org/doxygen/dirs.html 。在这个里面看目录，就比较清晰了，在clang目录下面一共就三个目录： docs、include和lib。为什么只有这三个呢？仔细研究和对比就会发现，如果你要研究Clang的内部实现，只需要这三个目录就够了，其他的目录和Clang核心没有任何关系，是一些基于Clang的工具，Clang的一些例子，或者是一些测试用例等。

现在看起来，Clang的结构已经很明显了。docs很明显放置的都是一些文档相关的内容，include放置的都是一些头文件。就只剩下一个lib目录了，下面是分类的目录，这个时候也可以推断出Clang的总体架构了，它的总体架构是基于库的。在Clang的官方文档“Clang" CFE Internals Manual （http://clang.llvm.org/docs/InternalsManual.html ）中，对Clang内部的介绍也是依据库来进行分类的。