LLVM 每周 - 第 4 期,2014 年 1 月 27 日
欢迎来到 LLVM 每周的第四期,这是一个每周新闻通讯(每周一发布),涵盖 LLVM、Clang 和相关项目的进展。这标志着运营的第一个月的结束,希望还有更多!LLVM 每周由 Alex Bradbury 提供。订阅未来的问题,请访问 http://llvmweekly.org 并将其传递给您认为可能感兴趣的任何其他人。请将任何提示或反馈发送至 [email protected] 或 @llvmweekly 或 @asbradbury(推特)。我一直保持着 @llvmweekly 推特帐户 在整个星期内更新,所以如果你想获得更频繁的新闻更新,请关注它。
本期文章的规范地址 可以在 llvmweekly.org 找到.
来自网络的新闻和文章
本周最大的编译器相关新闻是 GCC 邮件列表上的讨论。事情从 Eric S. Raymond 的帖子 开始,他建议 GCC 中的技术进步正受到对以绕过版权许可的方式重复使用 GCC 部分的担忧所阻碍。Ian Lance Taylor 回应 指出 GCC 现在有一个插件系统,尽管接口不稳定,但这在很大程度上阻止了这一讨论方向。然而,Richard Stallman 后来的邮件列表帖子 通过声称“LLVM 的存在对我们的社区来说是一个可怕的挫折,因为它没有被版权保护并且可以作为非自由编译器的基础”而被证明极具争议性。在网络上有很多关于这些评论的讨论,例如 LWN、Hacker News、Reddit、Slashdot 等。尽管我们许多人可能更喜欢非版权(“宽松”)的自由软件许可证,但 RMS 一直并长期以来一直认为,版权许可证最终能更好地传播自由软件并维护其自由。因此,我不清楚为什么这份邮件列表帖子会让许多人感到意外。我个人感到惊讶的是,他没有提到 BSD 样式许可证(LLVM 使用的许可证)中没有包含任何明确的专利授予(尽管 LLVM 确实有一个 专利政策 来帮助保护其用户)。
快速从有争议的主题转移,LLVM 项目本周取得了一个令人兴奋的里程碑。第 200000 个提交 已被应用。Takumi Nakamura 很幸运地成为该提交的作者。
Khronos 小组已 发布 SPIR 1.2 规范。SPIR 是一种标准化的中间表示,旨在与 OpenCL 一起使用,并基于 LLVM 3.2 IR。随着该版本的发布,Khronos 小组已开源了修改后的 Clang 3.2,它可以从 OpenCL C 程序生成 SPIR,以及一个模块验证器。
Joaquín M López Muñoz 发布了一个 比较 Clang 上哈希表性能的基准。他将 GCC 的 libstdc++-v3 与 LLVM 项目的 libc++ 进行比较。
剑桥(英国)LLVM 社交活动 重新开始,下一场活动将在 1 月 29 日晚上 7:30 举行。不幸的是,我无法参加,希望下次能参加!
在邮件列表上
Chandler Carruth 询问 LoopPass 和 LoopPassManager 是否可以移除。他列出了它们造成的混乱和问题,对我来说最糟糕的是,它们经常从循环外部修改 IR,从而打破了“循环传递”的隐式约定。讨论最终得出了一个建议,即 LoopSimplify、LCSSA 和 LoopVectorizer 成为函数传递。正如您从下面的 LLVM 提交部分中看到的,Chandler 很快提交了补丁来执行此操作,这些补丁已被应用。
Vadim 要求对他的想法 使用 LLVM 生成具有位置无关堆栈的代码 提供意见。这通常用于实现类似于 Python greenlets 的东西。Mark Seaborn 指向他所做的一些 类似工作,它将内存访问限制在一个地址空间范围。
Tom Stellard 已完成 针对 LLVM 次要版本的建议策略和流程.
Shea Levy,nixpkgs 的维护者,在邮件列表中写道 他遇到的问题,这些问题是在为 Nix 打包 LLVM 和 Clang 时遇到的。
Raul Silvera 要求对从数学内在函数中移除 ReadOnly 属性 提供意见,理由是浮点环境的变化(例如舍入模式)并没有被建模。正如 Raul 在随后的跟进中指出的那样,“我们目前似乎处于最糟糕的境地,因为我们不支持这个环境,但总是受到它的约束。”
Sebastien Riou 询问 如何强制 MachineFunctionPass 成为最后一个。Peter Cooper 建议,目前您可以将传递添加到
X86PassConfig::addPreEmitPass
的末尾,或者在调用 preEmitBass 之后以及添加 ASM 打印机之前添加传递。Jasper Neumann 发现了 LLVM 在生成的代码中留下不必要的寄存器移动 的各种情况。Andrew Trick 建议,可以在寄存器分配之后添加消除副本的窥视孔,但总体而言,由于它们对性能的影响很小,人们不愿意为了优化涉及多个物理寄存器副本的特殊情况而引入额外的复杂性。
David Chisnall 询问 LLVM 是否依赖于堆栈位于地址空间 0 的假设。Matt Arsenault 指出,OpenCL 局部变量目前通过创建全局变量而不是分配非默认地址空间来工作。他认为,这种限制源于编译器中的许多地方都假设地址空间是 0,并且从未通过检索相关指针的地址空间来进行检查。
Christian Schafmeister 发布了 他对即将发布的 C++ 重构工具的预告,该工具是用 Lisp 编写的。它利用了 clang 的 ASTMatcher/Refactoring 库。我期待着承诺的开源发布。
David Fang 发布了 关于 libc++ 在 powerpc-darwin 上的状况的摘要.
LLVM 提交
LoopSimplify 不再是 LoopPass,而是既是实用函数,也是 FunctionPass。这样做的动机是为了能够在运行 LoopSimplify 之后计算函数分析传递,但这种改变还有许多其他优点,在提交消息中进行了详细描述。 r199884。此外,LCSSA(循环闭包 SSA)传递被制作成一个带有函数传递的实用程序,而 LoopVectorizer 则变成了 FunctionPass。 r200067、r200074.
Constant Hoisting Pass 诞生了。 r200022.
InstCombine 学会了如何处理大多数 fmul/fvid/add/sub/mul/div 组合的向量。 r199598、r199602.
由于提交消息中描述的两个缺点,基于类型的别名分析暂时在 CodeGen 中使用别名分析时被禁用。 r200093.
LTO 获得了新方法,这些方法允许用户解析元数据节点、提取链接器选项以及从位码模块中提取依赖库。 r199759.
Sparc 后端现在支持内联汇编约束“I”。 r199781.
x86 后端允许对 movs/lods/outs 进行段和地址大小覆盖,从而修复了 bug 9385。 r199803 等等。
llvm-ar 不再两次打开或 fstat 文件。 r199815.
在使用 minsize 属性编译函数时,ARM 后端现在将使用文字池,即使是正常的 i32 立即数。 r199891.
R600 后端有很多活动。我没有时间适当地总结这些活动或挑选出最重要的提交,所以我建议感兴趣的人看一下提交日志。
JIT 现在支持 Sparc64。 r199977.
llvm-readobj 获得了对 PE32+ 格式(用于 Windows 64 位可执行文件)的支持。 r200117.
Clang 提交
Registry::getCompletions 已实现。这将返回给定上下文中的有效完成列表。 r199950.
函数和方法声明上的 getResultType 已重命名为 getReturnType,这是一个语义上更准确的名称。 r200082。类似地,getResultLoc 已重命名为 getReturnLoc。 r200105.
FunctionProtoType 中所有适用的访问器都已从
*argument*
重命名为*parameter*
。 r199686.当安装在系统根目录内时,Clang 被教导在它的安装 libdir 中查找 libc++ 等库。 r199769.
现在需要一个 module.map 文件才能加载模块。 r199852.
其他项目提交
lldb 学习了“step-avoid-libraries”设置,该设置允许用户列出要避免的库。 r199943.
在 compiler-rt 中,添加了对拦截和清理传递给 AddressSanitizer 和 ThreadSanitizer 中的 printf 函数的参数的支持。 r199729.
对 ThreadSanitizer 进行了修复,以防止在 fork 之后发生死锁。 r199993.
Dragonegg 现在可以使用 CMake 构建。 r199994.
compiler-rt 在其针对 ARMv4 的 udiv/umod 实现中获得了支持,ARMv4 缺少 bx 和 clz。代码更改还导致 Raspberry Pi(armv7,ARM1176)上的性能提高了 30% 以上,在 Cortex A9 上提高了 5-10%。 r200001.
在 Android 上的 AddressSanitizer 中,所有 AddressSanitizer 输出都将复制到系统日志。 r199887.
lld 获得了对发出 PE32+ 文件头的支持。 r200128.
lldb 现在支持 x86-64 上的 Haswell。 r199854.