之前有在公司主导过工具后端的实现。这里权当总结和提炼一下思路了。
早期版本的实现
早期的版本，由于技术实力的储备不足，当时走的路线是软件的前端 + LLVM工具链。从后端的角度来看，实现就相当简单，把工具的数据结构转换成等价的LLVM IR. 剩下的就让LLVM的工具链来完成二进制文件的生成就可以了。除了少量的配置LLVM优化pipeline的工作之外，基本上就不需要什么深入的开发。
看，LLVM就是这么省心！
(LLVM的质量还是很不错的，在编译生成ARM指令时，除了attribute的调整做了少量适配之外，基本没怎么大动)
走通了编译流程之后，紧接着的就是性能的需求。不管是编译时，还是运行时，都对于工具本身提出了很高的要求。
PGO, LTO用来优化编译时。同时，不停的缩减pipeline中核心Pass的数量。编译性能在提升的同时，运行性能一直稳定的保持不变。但是，很遗憾的是，LLVM工具链就像是一个大象。让它很灵巧的转身，几乎是不可能的事情。而工具本身的特点，让它不需要那么多LLVM的pass来进行优化运行时。但是很无奈的是，LLVM的后端并不像LLVM IR层的优化那样，可以定制一套很轻量化的优化。pass之间的耦合也非常严重。其次LLVM在后端的各种转换(SelectDAG, MachineIR, MC Layer, 等等)，自身就会带有不小的开销。这造成编译性能的优化达到了一个瓶颈。
虽然编译性能的重要性弱于运行性能ÿ