llvm:是否可以将验证和编译合并在一个阶段?

发布于 2025-01-01 16:54:50 字数 499 浏览 1 评论 0原文

一般来说,在编写 llvm 前端时,我们会采用 AST 并首先检查其语义是否定义良好。此后,我们将获取 AST 并执行 IR 构建阶段。 我想知道,直接在 AST 上执行 IR 构建阶段有多现实,如果在构建过程中发现错误,则恢复对模块对象的任何部分更改?

我假设需要这样的东西:

  • 删除定义的类型
  • 删除定义的全局
  • 我还缺少什么吗?

对此有什么想法吗?在失败的构建阶段之后,需要做什么来完全恢复模块更改的一般准则是什么?

现在,这是从乐观编译的角度思考,并在出现问题时优雅地失败。在当前的 LLVM 模型下,这很可能是完全不可能或不鼓励的。在这方面,一个清晰且有据可查的答案也是完全可以接受的

编辑 最后,我只想要一种合理的方法来增量添加功能,但可以优雅地恢复到模块和/或 的先前状态LLVMContext 如果函数构建失败。无论哪种首选方法都将完全令人满意。

谢谢!

Generally speaking, when writing a llvm frontend, one will take an AST and first check that its semantics is well-defined. After this, one will take the AST and perform the IR build phase.
I was wondering, how realistic is to perform directly the IR build phase onto the AST, and if errors are found during the build process, revert any partial changes to the module object?

I assume something like this would be required:

  • remove defined Types
  • remove defined Globals
  • anything else i'm missing?

Any ideas about this? what are the general guidelines of what needs to done for a clean revert of module changes after a failed build phase?

Now, this is thinking in terms of optimistically compiling, and failing gracefully it somethings goes wrong. It might very well be that this is completely impossible or discouraged under the current LLVM model. A clear and well-documented answer in this regard is also completely acceptable

Edit In the end, I just want a reasonable way to add functions incrementally but revert gracefully to previous state of module and/or LLVMContext if a function build fails. Whatever is the preferred approach for that will be entirely satisfactory.

thanks!

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

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

发布评论

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

评论(1

迷荒 2025-01-08 16:54:50

许多编译器(不一定与 LLVM 相关)将语义分析与代码生成混合在一起,因此绝对可以完成。但是,我对您提到的“恢复对模块对象的任何部分更改”感到困惑。当您开始构建 IR 模块并在 AST 中遇到语义错误时,您的计划是什么?你想吐槽一个不完整的模块吗?为什么?考虑任何常规编译器的工作方式,如果代码中存在语义错误(即引用未定义的变量),则不会创建任何输出。你想要一些不同的东西吗?

Many compilers (not necessarily LLVM-related) mix semantic analysis with code generation, so it can definitely be done. However, I'm puzzled by your reference to "revert any partial changes to the module object". When you start building an IR module and encounter a semantic error in the AST, what is your plan? Do you want to spit an incomplete module? Why? Thinking about the way any regular compiler works, if there are semantic errors in the code (i.e. reference to an undefined variable), no output is created. Would you like something different?

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