Transitioning to MIR

[nikomatsakis]

This reminds me of another bit of MIR work that I would like to do, which is to “re-type-check” the MIR as a sanity check. This should be much simpler than before since there would be no inference to be done.

[arielb1]

rvalue checking – because identifying rvalues is trivial in MIR

Absolutely

dead-code – because MIR is simpler to traverse and it is more evident when something is being used reachability – as above

Nice, but these is pretty stable (so low value).

match checking – because I think we do something basically equivalent during MIR construction; see below

The algorithms are somewhat different, and patterns will be cleaned-up in the HIR work - may be better to separate them.

effect – this is trickier, because the scope of unsafe regions is not preserved in MIR right now; however, identifying derefs and casts is very easy, so I feel like the code would be more robust if impl’d on MIR. Therefore, I think we should add information to track unsafe regions to MIR.

this is a rather trivial pass, and it rather depends on lexical nesting, so I am not sure.

intrinsicck – because it is easier to identify calls to transmute

The utility of this pass is dubious because of associated types - we should probably make it a lint (but we need ABI-accessing lints for that).

trans

of course

[eefriedman]

I had at some point hoped that we could perhaps build the MIR for one function at a time and throw it away in between fns, but that doesn’t work with monomorphization in trans I fear.

You mean, because we don’t know what monomorphizations we will need before trans? We could add a separate monomorphization pass. Although, in the MIR world, such a pass would be an MIR pass, so I guess that doesn’t work out. It’s possible we might want such a pass for other reasons, though; for example, it would probably produce better diagnostics.

[nikomatsakis]

The algorithms are somewhat different, and patterns will be cleaned-up in the HIR work - may be better to separate them.

If we tie the code generation to this check, it has the advantage that they will not get out of sync. But I’ll take a stab at it perhaps and see how well it works. I’ve not made up my mind. The main challenge is constructed a human-readable counter-example, but that seems fairly straightforward as well – when we reach the point in the algorithm where we detect a missing case, we have a path and a test outcome (e.g., enum variant).

[nikomatsakis]

You mean, because we don’t know what monomorphizations we will need before trans? We could add a separate monomorphization pass.

Yes, that’s what I mean. It is plausible that we could just do monomorphization expansion as a pre-pass and make a complete list of what we will need, but I’m not sure it’s worth the trouble.

[nikomatsakis]

this is a rather trivial pass, and it rather depends on lexical nesting, so I am not sure.

The main advantage to doing it on the MIR is the fact that all derefs are clean and explicit. It might actually be nicer to just run it on the HAIR that is used as input to the MIR, which also shares this property (eventually, I’d like to have typeck produce actual HAIR).

[arielb1]

The main advantage to doing it on the MIR is the fact that all derefs are clean and explicit. It might actually be nicer to just run it on the HAIR that is used as input to the MIR, which also shares this property (eventually, I’d like to have typeck produce actual HAIR).

Derefs? only raw pointer derefs are dangerous, and these are explicit. Method calls are checked via the method map. Otherwise, we only need to use expr_ty_adjusted (we don’t - https://github.com/rust-lang/rust/issues/28776 - but the potential for screw-ups is endless anyway).

[nikomatsakis]

Derefs? only raw pointer derefs are dangerous, and these are explicit.

Ideally, I think they should support autoderef. I’m not really sure why they don’t except…that they don’t. (Though at some point the fact that it would have been very hard to enforce safety in that case was a factor, but the current setup makes it easier to do.)

[Gankro]

Woah woah woah; are yous seriously suggesting raw pointers auto-deref?

Keep in mind they have several methods.

[arielb1]

Ideally, I think they should support autoderef.

That would be very scary - even within an unsafe block, I prefer to keep raw pointer operations explicit.

[nikomatsakis]

Woah woah woah; are yous seriously suggesting raw pointers auto-deref?

Yes, I was. You don’t want that? I’m surprised. I find it so annoying to write code like (*x).foo.

Keep in mind they have several methods.

True. So does Rc, though (for better or worse).

That would be very scary - even within an unsafe block, I prefer to keep raw pointer operations explicit.

Well, I don’t agree, but it doesn’t really matter. If I ever make a concrete proposal, we can argue about it there. I was mostly just trying to argue that we want to be as clear as possible about identifying unsafe operations. I do agree that the lexical scoping of unsafe blocks is not a good fit for MIR, but clearly identifying what operations take place IS a good fit.

In any case, * is no longer the only potentially unsafe operator. Per RFC 1240, taking the address of a field of a packed struct is also unsafe. To make this check work properly for match statements seems like it will require something like the EUV, which I expect to go away in favor of MIR.

[Gankro]

Rc has no methods outside of trait impls: https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html

[nikomatsakis]

Rc has no methods outside of trait impls: https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html

Huh. OK, I stand corrected. I actually checked rustdoc before writing that though, not sure what I was looking at. Maybe a trait impl.

[nikomatsakis]

Or perhaps Arc: http://doc.rust-lang.org/std/sync/struct.Arc.html#method.downgrade though I see those are unstable, which seems good.

[arielb1]

To make this check work properly for match statements seems like it will require something like the EUV, which I expect to go away in favor of MIR.

We really should just make our HIR pattern story better, and then we could use just the HIR (+ visit_pat).

Anyway, I don’t want the MIR to be involved with lexical scoping. Unsafety checking is a lexical operation.

[nikomatsakis]

We really should just make our HIR pattern story better, and then we could use just the HIR (+ visit_pat).

Perhaps. Do you have a more specific proposal in mind? Figuring out just what is being borrowed does require at least a bit of calculation over the HIR, as mem_categorization does today.

Anyway, I don’t want the MIR to be involved with lexical scoping. Unsafety checking is a lexical operation.

I understand this feeling and I agree that in general lexical scoping is not a good fit for the MIR. That said, MIR DOES do a good job of exposing the kind of low-level details effect checking wants to see.

Overall my feeling is that effect checking lies somewhere in the middle. So we can either stretch HIR down, and do more safety analysis on HIR that I might prefer to do, or bend MIR a bit up, and track either lexical scopes or the unsafety setting. I guess the right answer will depend on just what HIR winds up looking like.

[arielb1]

Perhaps. Do you have a more specific proposal in mind? Figuring out just what is being borrowed does require at least a bit of calculation over the HIR, as mem_categorization does today.

Thinking about it, references to fields of packed structs is an lvalue problem (patterns have their own different set of problems), so it may make sense to compute safety during lowering, use that to add an unsafe bit to MIR, and do the check later.

[Aatch]

I’m thinking that a general transformation pass pipeline for MIR functions would be useful. There are a few optimisations that can be done that LLVM struggles with because we can’t quite encode the correct semantics in.

I think that the basic passes we need are: drop optimisation, overflow check insertion, inlining (maybe), and some sort of copy elimination based on dataflow (which should cover NRVO at the same time).

[nikomatsakis]

I should probably spell out my thoughts here more. @arielb1 and I had a brief chat on IRC the other day and it seemed like we had slightly different thoughts so it’s worth discussing more widely. My general feeling is that we should expect to do optimizations on the MIR when it makes sense, and that after the static safety checking is done, we may want to edit the MIR in ways that would no longer type check (but which we believe to be sound).

I also think that, whenever it makes sense, we should do optimizations on the MIR rather than doing it “on the fly” during trans. I believe this will result in more readable code (because the MIR is simpler); more portable optimizations if we ever move beyond LLVM; and more debugable results, because we can easily dump the MIR at any point and observe what has been done (this is always hard with LLVM output, imo).

Some examples of things I would like to do on the MIR:

1. Expose the dynamic drop flags as MIR temporaries. After borrowck is done, rewrite DROPs to drop only the paths they need to, and to take a boolean argument that is either a constant true or else a stack variable in the cases where dynamic drop is required.
2. Constant propagation, particularly as it is useful for deciding what to promote (in LLVM) to static values etc.
3. Removing temporaries and stripping out other assignments that serve no logical role (e.g., zero-sized types). However, we must be cautious around destructors here: that said, because calls to DROP and so forth are already inserted explicitly in the MIR, we may not have to worry in particular.
   • example: rewriting tmp0 = ..; tmp1 = ..; x = Foo { f1: tmp0, f2: tmp1 }; to x.f1 = ...; x.f2 = ...;
4. Removing no-op coercions etc.

[arielb1]

drop flags would have to be allocas, not temporaries.