[HN Gopher] A deeper look into the GCC Rust front-end
___________________________________________________________________
A deeper look into the GCC Rust front-end
Author : chmaynard
Score : 26 points
Date : 2022-10-11 10:20 UTC (12 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| puffoflogic wrote:
| > unsafe, of course, [] disables a lot of the checks that the
| compiler makes.
|
| This is, of course, not true. It allows only two things: (1)
| allow access through pointers and union fields (2) allow calling
| unsafe or external functions.
|
| Neither of these is really a "check", more like "some operation
| that just isn't present in safe rust and is present in unsafe
| rust". They aren't conditionally allowed in safe rust; they just
| aren't allowed. In particular unsafe does not alter the operation
| of borrowck by one jot.
| steveklabnik wrote:
| When I'm back at my computer I'm going to reply in thread, ha.
| It's very strange to see something you've written being
| presented as authoritatively saying something you didn't say!
|
| (And it's more than those two things, but you're still right in
| general that unsafe _adds_ , it does not _remove_.)
| puffoflogic wrote:
| I'm trying to think what "more" is. I guess I missed inline
| asm, although I'd probably lump it in with "external
| function". Static mut, technically, but I don't really
| consider those part of the current rust language; a
| historical accident which should be read as `UnsafeCell`.
| Therefore I'm going to lump that in with unsafe functions
| too, albeit an invisible one.
|
| ETA: I found your lwn comment. I forgot entirely about unsafe
| traits and I would say those are entirely different from my
| two categories. So, three things.
| b3morales wrote:
| Having two IRs (or even having a 1st-stage IR for each frontend
| language) sounds like something that a compiler project would
| want to avoid in the long term. I wonder how the IR that's being
| added for Rust will end up influencing the "regular" IR.
| steveklabnik wrote:
| 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.
| MuffinFlavored wrote:
| > rustc has three already
|
| Can you expand on this? What are they? I would've thought
| rustc outputs only 1 IR?
| steveklabnik wrote:
| 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.
| fzzzy wrote:
| There are different stages of ir which allow for different
| optimizations.
| pretty_dumm_guy wrote:
| > Having two IRs (or even having a 1st-stage IR for each
| frontend language) sounds like something that a compiler
| project would want to avoid in the long term
|
| Can you please share the reason behind why it should be this
| way ?
___________________________________________________________________
(page generated 2022-10-11 23:02 UTC)