iOS 开发中的 LLVM 与 GCC

发布于 2024-10-10 15:48:45 字数 247 浏览 9 评论 0原文

在最新的 iOS SDK 中,Apple 提供了三种编译器选项:GCC、LLVM with Clang 和 LLVM-GCC。我或多或少明白这3个是什么意思,LLVM和Clang是什么,等等。我不知道这对于 iPhone 开发者来说实际上意味着什么。截至 2011 年 1 月,我现在应该使用其中哪一个? LLVM 是否足够成熟,我可以安全地使用它,而不会经常遇到其中的错误?切换到 LLVM 还有其他缺点吗?如果确实如此,那么速度优势是否超过了它们?除了速度之外还有其他原因吗?

In latest iOS SDK, Apple provides three compiler options: GCC, LLVM with Clang and LLVM-GCC. I understand more or less what these 3 mean, what LLVM and Clang are, and so on. What I don't know is what this means in practice for iPhone developers. Which of these should I use at this point, as of January 2011? Is LLVM mature enough that I can use it safely without stumbling on bugs in it too often? Does switching to LLVM have any other disadvantages? If it does, then does the speed advantage outweigh them? Are there any other reasons to switch except speed?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

小瓶盖 2024-10-17 15:48:45

更新:因为人们仍在寻找这个答案,所以我觉得我应该提供合适的更新。到目前为止,我希望大家清楚 Clang 绝对是编程的最佳选择,Clang 是新版本 Xcode 中的默认编译器,并支持 ARC 以及新的和即将推出的语言结构(数组和字典下标、文字等) 。几乎绝对没有理由再使用 GCC 进行编译,并且对于使用 ARC 和新功能的代码库,使用普通 GCC 不再相关或不可能(LLVM-GCC 可能支持这些功能,但它与 Clang 相比没有任何优势,因为 Clang 完全是稳定的)。


到目前为止(Xcode 4.0 beta 中包含了 LLVM-2.0),LLVM 已经足够成熟,可以用于生产代码。它的编译速度比 GCC 快一点,生成的代码也更快,因此只要有可能就使用它(基本上,如果有更好的东西可用,请尽量避免使用 GCC)。标准 Xcode 3.2.5 安装包含 LLVM-1.6(不是最新的),因此我建议运行一些速度测试以查看 GCC 和 LLVM 之间是否存在明显差异,或者从源代码编译 Clang 并获取最新版本。

本质上,不再需要 GCC,LLVM + Clang 就足够了。

Update: Because people are still finding this answer, I feel like I should provide a suitable update. By now, I hope it's clear that Clang is absolutely the way to go when programming, with Clang being the default compiler in the newer versions of Xcode and supporting ARC and new and upcoming language constructs (array and dictionary subscripting, literals, etc.). There's almost absolutely no reason to compile with GCC anymore, and for codebases using ARC and new features, using plain GCC is no longer relevant or possible (LLVM-GCC may support these features, but it provides no advantage over Clang now that Clang is completely stable).


By now (with LLVM-2.0 included in the Xcode 4.0 beta), LLVM is mature enough for production code use. It compiles a little quicker than GCC, and produces faster code, so use it whenever you can (pretty much, try to avoid GCC if something better is available). The standard Xcode 3.2.5 install contains LLVM-1.6 (not the latest), so I'd recommend either running some speed tests to see if there's a noticeable difference between GCC and LLVM, or compiling Clang from source and getting the latest version.

Essentially, there's no need for GCC any more, LLVM + Clang is more than enough.

呆头 2024-10-17 15:48:45

好吧,我认为下面的答案都不能说明全部情况,所以这是我对我的问题的回答:

  • LLVM 编译代码的速度比 GCC 更快,可能会创建运行速度更快的代码,并且 Clang 前端提供更准确的错误消息比 GCC 多——所以肯定有切换的理由;

  • 也就是说,最新稳定的 Xcode (LLVM 1.6) 提供的版本还不是 100% 稳定,如果你不幸运的话,你可能会遇到一些小错误。因此,如果你想安全,你应该要么从源代码编译最新的 LLVM (2.0),要么在接下来的几个月里坚持使用 GCC;

  • 几个月后,可能当 Apple 发布 Xcode 4 时,LLVM 2.0 将成为 Xcode 默认附带的版本,然后我们都应该能够安全地切换到它。

感谢所有回复的人,如果我有什么错误,请随时纠正我。

Ok, I think none of the answers below tell the whole story, so here's my take on a response to my question:

  • LLVM compiles code faster than GCC, may create code that runs faster, and the Clang frontend provides more accurate error messages than GCC – so there are definitely reasons for switching;

  • that said, the version provided with latest stable Xcode (LLVM 1.6) is not 100% stable yet, you can run into some minor bugs if you're unlucky. So if you want to be safe, you should either compile the latest LLVM (2.0) from source, or stick to GCC for the next few months;

  • in a few months, probably when Apple releases Xcode 4, LLVM 2.0 will be the version that ships with Xcode by default, and then we should all be able to switch to it safely.

Thanks to everyone who responded, feel free to correct me if I got something wrong.

薔薇婲 2024-10-17 15:48:45

我有一个应用程序,当使用 LLVM 2.0 编译时,在运行 iOS 3.1.3 的原始 iPhone 上启动时似乎会崩溃,但使用 LLVM-GCC 运行得很好。我支持回到 iOS 3.1 所以这是致命的。不确定 LLVM 2.0 和我拥有的某些特定代码之间是否存在交互,但如果您需要支持 iOS 3.x,似乎最好避免使用 LLVM,除非您可以在旧设备上进行彻底测试。


更新:问题似乎与设备硬件有关,而不是 iOS 版本。第一代和第二代 iOS 设备似乎受到影响:原始 iPhone、iPhone 3G 以及第一代和第二代 iPod Touch。我相信这意味着它仅限于 ARMv6 架构。

此外,通过 Xcode 的调试器运行调试版本可以正常工作,而通过 iTunes 安装的发布版本则不行。所以这可能是CPU架构和LLVM 2.0优化级别之间的相互作用。

但无论如何,暂时避免;)

I have an app that seems to crash on launch on the original iPhone running iOS 3.1.3 when compiled with LLVM 2.0, but runs just fine with LLVM-GCC. I support back to iOS 3.1 so this is fatal. Not sure if there's an interaction between LLVM 2.0 and some specific code I have, but it seems best to avoid LLVM if you need to support iOS 3.x unless you can test thoroughly on legacy devices.


Update: It seems that the issue is with the device hardware rather than iOS version. 1st and 2nd generation iOS devices seems to be affected: Original iPhone, iPhone 3G, and 1st and 2nd gen iPod Touch. I believe this means it's limited to ARMv6 architectures.

Also, running a debug build via Xcode's debugger works fine, while release builds installed via iTunes do not. So it might be an interaction between CPU architecture and optimization level with LLVM 2.0.

But in any case, avoid for now ;)

我的黑色迷你裙 2024-10-17 15:48:45

切换到 Clang 的另一个主要原因是更准确(列号和行号范围)和可读的错误消息。

Another major reason to switch to Clang is more accurate (column & line number ranges) and readable error messages.

断桥再见 2024-10-17 15:48:45

在最新的 WWDC10 期间,他们特别鼓励开发人员使用更新的 LLVM 编译器。我忘记了他们详细介绍它的确切内容 - “Xcode 中的新内容”之一。基本上他们建议尽可能使用 LLVM-2.0,否则使用 LLVM-GCC 并完全避免单独使用 GCC。

如果您是注册的 iOS 开发人员,您可以在以下位置免费观看大部分会议:
http://developer.apple.com/videos/wwdc/2010/

During the latest WWDC10 they made a point of encouraging developers to use the more current LLVM compiler. I forget the exact tract that they covered it in detail - one of the "new in Xcode". Basically they suggest using LLVM-2.0 when possible, otherwise LLVM-GCC and to avoid GCC alone completely.

If you're a registered iOS developer, you can view most of the sessions free at
http://developer.apple.com/videos/wwdc/2010/

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文