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