在LLVM tutorials有如何编写简单的 JIT 编译器的说明。不幸的是，本教程中的词法分析器和解析器是手动编写的。我在想，这样的解决方案适合学习目的，但不适合编写复杂的、生产就绪的编译器。似乎 GCC 和其他一些“大编译器”是手写的。但我认为，所有这些解析器生成器在编写自己的编译器时都提供了很大的插入力(尤其是当您独自完成时，没有团队)。
是否可以将任何现有的解析器生成器(如 Bison/Antlr/Packrat/Elkhound 等)与 LLVM 一起使用来创建 JIT 编译器？我希望能够不断地(不是一开始就)用表达式“喂养”解析器，并在运行时编译它们。
另外，我发现了很多关于“最好的、现代的”解析器生成器的问题(比如这个:https://stackoverflow.com/questions/428892/what-parser-generator-do-you-recommend)。如果可以使用这些工具来创建 LLVM JIT 编译器，我将不胜感激任何额外的提示和建议，在此特定情况下，哪种工具在性能和灵 active 方面最好。
最佳答案
使用像 bison 或 antlr 这样的解析器生成器有很多优点，尤其是在您开发语言时。毫无疑问，您最终会在进行过程中对语法进行更改，并且您希望以最终语法的文档结束。从文档中自动生成语法的工具非常有用。它们还可以帮助您确信该语言的语法是 (a) 您认为的那样并且 (b) 没有歧义。
如果您的语言(与 C++ 不同)实际上是 LALR(1)，或者更好的是 LL(1)，并且您正在使用 LLVM 工具来构建 AST 和 IR，那么您不太可能需要做很多事情不仅仅是写下语法并提供一些简单的操作来构建 AST。这会让你坚持一段时间。
除了“真正的程序员不使用解析器生成器”的偏见之外，人们最终选择构建自己的解析器的通常原因是，为语法错误提供良好的诊断并不容易，尤其是 LR(1)解析。如果这是你的目标之一，你应该尝试使你的语法 LL(k) 可解析(使用 LL(k) 提供良好的诊断仍然不容易，但它似乎更容易一些)并使用 LL(k)类似 Antlr 的框架。
还有另一种策略，即首先使用比 LL(1) 更灵活的 LALR(1) 解析器以最简单的方式解析程序文本，甚至不尝试提供诊断。如果解析失败，您可以使用更慢的、甚至可能回溯的解析器再次解析它，它不知道如何生成 AST，但会跟踪源位置并尝试从语法错误中恢复。在不使 AST 无效的情况下从语法错误中恢复甚至比继续解析还要困难，因此不尝试有很多要说的。此外，跟踪源位置真的很慢，如果您不必生成诊断信息(除非您需要它来添加调试注释)，它就不是很有用，因此您可以通过不打扰来加快解析速度位置跟踪。
就个人而言，我对 Packrat 解析有偏见，因为不清楚 PEG 解析的实际语言是什么。其他人对此并不介意，YMMV。
关于c++ - 使用 Bison/Antlr/Packrat/Elkhound/编写的 LLVM JIT 解析器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14736194/