Architectural inquiry: Trade-offs between direct AST-to-LLVM codegen vs. Intermediate Representation

[ProtossX]

Hi Rusty Maintainer Team,

First of all, huge thanks for open-sourcing Rusty. I'm currently leading a project to build an IEC 61131-3 ST compiler for industrial use, and Rusty has been an invaluable reference for us to understand the mapping between ST and LLVM.

I am currently at an architectural crossroads and would love to hear your insights.

I noticed that Rusty generates LLVM IR directly from the AST, skipping a custom middle-end IR. While studying the source code (specifically the codegen module), I realized this approach keeps the architecture lean but seems to result in a relatively complex codegen logic to handle state and control flow.

My question is: If you were to start Rusty from scratch today, would you stick with the direct AST -> LLVM approach, or would you consider introducing a lightweight Mid-level IR (to handle things like flattening control flow or ST-specific semantics) before lowering to LLVM?

I'm trying to decide whether the maintenance cost of a custom IR is worth it for an ST compiler, or if the direct approach (like Rusty's) is actually the pragmatic sweet spot.

Your experience would be incredibly helpful for our architectural decision.

Best regards, Tony

[TheColonel2688]

Im not a RuSTY dev but.... instead of reinventing the wheel you could use and contribute to RuSTy. It uses LGPL so it can be used in commercial products, as long as you don't statically link it. We should all focus on one open source tool instead of splitting our resources. Vendor Lock in is the root of all evil in the PLC world.

…

On Mon, Dec 1, 2025, 9:36 PM ProtossX ***@***.***> wrote: Hi Rusty Maintainer Team, First of all, huge thanks for open-sourcing Rusty. I'm currently leading a project to build an IEC 61131-3 ST compiler for industrial use, and Rusty has been an invaluable reference for us to understand the mapping between ST and LLVM. I am currently at an architectural crossroads and would love to hear your insights. I noticed that Rusty generates LLVM IR directly from the AST, skipping a custom middle-end IR. While studying the source code (specifically the codegen module), I realized this approach keeps the architecture lean but seems to result in a relatively complex codegen logic to handle state and control flow. My question is: If you were to start Rusty from scratch today, would you stick with the direct AST -> LLVM approach, or would you consider introducing a lightweight Mid-level IR (to handle things like flattening control flow or ST-specific semantics) before lowering to LLVM? I'm trying to decide whether the maintenance cost of a custom IR is worth it for an ST compiler, or if the direct approach (like Rusty's) is actually the pragmatic sweet spot. Your experience would be incredibly helpful for our architectural decision. Best regards, Tony — Reply to this email directly, view it on GitHub <#1556>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCZEX3CZGVIUEJHQKA4GED37T3JJAVCNFSM6AAAAACNXYW3ZWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGE4TQMJQGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ghaith]

Technically you can also statically link LGPL code, the only thing you will then only be required to provide the object files for the closed source part so that a user can re-link another version of RuSTy :)

[ghaith]

Hello @ProtossX

Thank you for your comments.
If you do find the project useful, I think we could all benefit from a common compiler with more users. The more companies that use our base, the more we get compatible with niche cases :)

That being said, the question you ask is something we discuss a lot internally. I think there are great benefits to a MIR, and I think rusty will introduce one at some point.

Should we have done it at the start? I don't know. It greatly simplifies codegen yes, but that complexity moves elsewhere. I believe it is a better tradeoff than a complex codegen like we have now, but it is important to keep your goals in mind and at the start and not over engineer.
If you can fit a MIR in your design from the start, go for it sure it will make it easier to maintain because you can simplify your AST before going into codegen as you said, remember though you are still doing the same steps, only earlier and it might be beneficial at the start to just do the codegen and get a system compiling and then optimise it.

[ProtossX]

Thank you so much for the thoughtful response!

Your perspective on the trade-offs between MIR and complex Codegen is really insightful. I especially appreciate the advice on not over-engineering at the start—it's easy to get trapped in designing the 'perfect' architecture. I'll definitely keep that in mind as I move forward.

I also completely agree with your vision: a common, robust compiler base benefits everyone in the ecosystem. I'm looking forward to seeing how Rusty evolves (and potentially the introduction of MIR in the future!).