虽然通过各种关于LLVM和自己的文档的文章阅读，但我已经看到了一些关于其IR的向后兼容性的引用。很难理解LLVM文本IR与各种版本二进制表示之间兼容性的不对称
很多关于IR的文件中提到，它是不稳定的，可以在几乎任何休息时间。但是，它也经常提到位码IR与给定的特定LLVM版本的文本IR更加向后兼容（正如'经常在更多版本中有效'一样）。
我的理解是字节码 - >位码转换几乎是一个直接映射。了解这一点，为什么/它如何与文本IR不兼容？我似乎无法找到驱动这种行为的实际机制的文档。这种关于IR兼容性声明
一个例子可以在这里找到：http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
谈到作为一个开发者，而不是一个开发LLVM。
，你会想象，该位码更像是具有特定指令集多达64位的是，直到量子计算机指令很受欢迎，很少会更改虚拟机。随着新的64位芯片交付增量增强，“附加”新的位代码处理并不是大手术。
的IR，在另一方面，是一种文本表示，将经历一次或多次去要么位码或机器代码。为了支持新的功能，显然有一个网络“添加”（新指令）以及现有的修改。这不仅会影响IR语法分析器/发射器，还可能会影响它们之间使用的许多中间/短暂数据模型。显然这也会影响C/C++ LLVM API。非常昂贵的命题确实能够保持向后兼容性。
我认为LLVM开发人员选择来承诺更多的位代码兼容性，因为有更明显的使用情况受益于向后兼容的位代码比文本表示。
您可能例如存储和分发库，LLVM位码并将其加载到某种刚刚在时间编译解释为用户的语言。每当解释器升级时必须升级位码可能不方便。 Bitcode是一个机器接口，它具有良好定义的兼容性。
考LLVM IR更经常用于调试，文件，或LLVM，其中无论何时改变（不频繁的）改变到表示由比较实用任何失败的代码的内部测试。中间代码似乎不太可能长期存储或广泛分布。
由于维护向后兼容性可能会对实现工作（例如C++解析器）和语言的未来发展（想想现代编程语言在处理回顾性明智的过去决策时所面临的困境）产生负面影响，因此， LLVM社区只有在获得明显利益时才选择这样做。我不认为格式中存在固有的技术原因，因为这两种格式都必须经过正确的解析和处理。