Transitioning to MIR

[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.

[nikomatsakis]

a “temporary” in MIR is just a compiler-generated variable (i.e., it IS an alloca). (Though at present we don’t assign to temporaries more than once, I don’t think.)

[oli-obk]

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).

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.

Wouldn’t it be better to move to an even lower representation instead of declaring “now the MIR doesn’t type check anymore”. This representation would then have no notion of dropping, but explicitly contain the drop flag and a “drop terminator” (or even already a call to the drop glue?)

[nikomatsakis]

Wouldn’t it be better to move to an even lower representation instead of declaring “now the MIR doesn’t type check anymore”.

The way I see it, we ARE moving to a lower-level representation by declaring that MIR doesn’t have to type-check anymore. That is, we can have two ‘logical’ representations that are both using the same compiler data-structures. Changing to an ACTUAL different IR is overhead – both in terms of compiler maintenance and potentially runtime – and I think MIR (possibly some edits over time) is at a pretty low-level of abstraction that is quite suitable for most optimizations we might do. It’s worth pointing out that MIR already includes a number of bits of type-safety that have been desugared – for example, bounds checking – and hence which are no longer easy to check, and I don’t think the things I have in mind are so very different.

However, it may be that we can devise other ways to achieve the same effect. I think @arielb1 had some suggestions along these lines. This could also be fine. I basically just don’t want to push work onto trans or elsewhere. And certainly I see the potential value in retaining invariants over MIR so that we can have “sanity check” assertions – I just don’t think it outweighs the value of doing things in straight-forward ways and at the MIR level, rather than at LLVM level.

[nikomatsakis]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.