News for hackers. Stuff that matters.
Re:A deeper look into the GCC Rust front-end by steveklabnik on Tuesday October 11, 2022 @01:08PM (#33165876)
Many many compilers have multiple IRs. It’s very normal. rustc has three already, last time I checked, and that’s not counting llvm-IR. Non-lexical lifetimes was gated on adding an additional IR to rustc, even.
Re:A deeper look into the GCC Rust front-end by MuffinFlavored on Tuesday October 11, 2022 @05:37PM (#33169553)
> rustc has three already

Can you expand on this? What are they? I would've thought rustc outputs only 1 IR?

Re:A deeper look into the GCC Rust front-end by fzzzy on Tuesday October 11, 2022 @05:51PM (#33169691)
There are different stages of ir which allow for different optimizations.
Re:A deeper look into the GCC Rust front-end by steveklabnik on Tuesday October 11, 2022 @06:41PM (#33170190)
I haven't been paying close attention lately, but for the last few years, compilation looked something vaguely like this:

* AST - abstract syntax tree, created from lexing/parsing

* HIR - high level IR

* THIR - typed high level IR

* MIR - mid-level IR (this is the one that enabled non-lexical lifetimes)

* LLVM IR - given to LLVM to generate the final binary.

If you want to learn more, the rustc dev guide has a bunch of details https://rustc-dev-guide.rust-lang.org/hir.html

> I would've thought rustc outputs only 1 IR?

Yeah, I mean these are in stages. One goes to the next goes to the next, and there's only one output, but that doesn't mean there aren't a bunch in the middle.

Different IRs are good at different things. MIR is based around the control-flow graph, which is also what non-lexical lifetimes are based on, so it's much easier to implement against MIR than it would have been against HIR.

Re:A deeper look into the GCC Rust front-end by philberty on Thursday October 13, 2022 @10:59AM (#33191928)
Thanks @steveklabnik we basically have the same in gccrs:

1. AST 2. HIR 3. THIR (side-table lookups) 4. GCC Generic

We basically skip MIR in gccrs.

Its pretty sensible to have other IR's, we have many passes in gccrs simplifying things so the graph of what your working with is simpler and simpler each time.

I mean in GCC for C++ for example they use GENERIC and add a bunch of custom tree-codes such as LAMBDA_EXPR or TEMPLATE stuff for example then they keep substituting etc and finally as part of handing off to GCC middle-end it triggers the gimplification of all of these custom tree codes. So even the C++ front-end you could argue has two IR's.

Re:A deeper look into the GCC Rust front-end by steveklabnik on Thursday October 13, 2022 @12:29PM (#33193237)
Good to know, thanks! I’m excited to see gcc-Rama develop, I just haven’t had time to learn how any of it works. Keep up the good work!
Re:A deeper look into the GCC Rust front-end by steveklabnik on Friday October 14, 2022 @03:28PM (#33207815)
...gcc-rs. thanks autocorrect.
Re:A deeper look into the GCC Rust front-end by b3morales on Wednesday October 12, 2022 @12:21PM (#33179245)
Those are serial, though, as I understand it -- each feeds into the next. The gccrs situation sounds like there are two parallel implementations.

Please correct me if I'm wrong; I'm not trying to pretend I am any kind of expert here.

Re:A deeper look into the GCC Rust front-end by steveklabnik on Wednesday October 12, 2022 @03:54PM (#33182148)
I don’t know anything about how this project is architected, but

> It's used for type checking and error verification; once that's done, it can be translated and handed to the GCC mid-layer.

Sounds the same serial thing to me.