Stream: t-compiler/wg-mir-opt

Topic: 2020.01.07 MIR 2.0 meeting


Santiago Pastorino (Jan 07 2020 at 14:21, on Zulip):

@nikomatsakis @oli @eddyb we have MIR 2.0 next steps meeting in ~ 40 mins

oli (Jan 07 2020 at 14:31, on Zulip):

the current document is located at https://hackmd.io/aQ8y79EfS72VCUoEmzLQpg

nikomatsakis (Jan 07 2020 at 15:00, on Zulip):

Hey everyone

Santiago Pastorino (Jan 07 2020 at 15:01, on Zulip):

hi Niko

Santiago Pastorino (Jan 07 2020 at 15:01, on Zulip):

@oli @eddyb seems like is time, hi everyone!

oli (Jan 07 2020 at 15:01, on Zulip):

hey

Santiago Pastorino (Jan 07 2020 at 15:01, on Zulip):

as @oli pointed out we have https://hackmd.io/aQ8y79EfS72VCUoEmzLQpg

oli (Jan 07 2020 at 15:01, on Zulip):

@eddyb is on mobile, so flaky around zulip

Santiago Pastorino (Jan 07 2020 at 15:02, on Zulip):

:+1:

Santiago Pastorino (Jan 07 2020 at 15:02, on Zulip):

I think there were other documents but this should contain everything at least all the stuff I know about

oli (Jan 07 2020 at 15:02, on Zulip):

I tried to link the other documents at the bottom

Santiago Pastorino (Jan 07 2020 at 15:02, on Zulip):

is there anything else related to MIR 2.0 that's not included in the document?

oli (Jan 07 2020 at 15:02, on Zulip):

but yea, this is the current "active" plan

Santiago Pastorino (Jan 07 2020 at 15:02, on Zulip):

:+1:

nikomatsakis (Jan 07 2020 at 15:03, on Zulip):

ok, I'm going to look it over real quick

Santiago Pastorino (Jan 07 2020 at 15:03, on Zulip):

so one of the last pieces that is not already merged is https://github.com/rust-lang/rust/pull/67000/

nikomatsakis (Jan 07 2020 at 15:03, on Zulip):

of these, I feel like removing deref + index from the list of projections is "different in kind" from the others

nikomatsakis (Jan 07 2020 at 15:04, on Zulip):

i.e., interning and things are basically perf optimizations

Santiago Pastorino (Jan 07 2020 at 15:04, on Zulip):

with that we will have promoted being constants instead of statics, we won't have statics anymore, and neither PlaceBase, so Place would be Local + projections

nikomatsakis (Jan 07 2020 at 15:04, on Zulip):

but don't have a "dramatic" effect on MIR

nikomatsakis (Jan 07 2020 at 15:04, on Zulip):

it seemed like @Santiago Pastorino that #67000 had a few implications

Santiago Pastorino (Jan 07 2020 at 15:04, on Zulip):

yeah maybe we should define what's worth discussing first but my guess is removing deref, index and field?

nikomatsakis (Jan 07 2020 at 15:04, on Zulip):

I'm thinking of the question of what's a legal static etc

nikomatsakis (Jan 07 2020 at 15:05, on Zulip):

and @RalfJ's soundness concerns around promotion

nikomatsakis (Jan 07 2020 at 15:05, on Zulip):

but I guess that's probably somewhat orthogonal -- i.e., we already have the behavior in question that is sort of dubious

nikomatsakis (Jan 07 2020 at 15:05, on Zulip):

what does "Formalizing out parameters (or args passed by pointer because they are too large)" mean?

Santiago Pastorino (Jan 07 2020 at 15:05, on Zulip):

it seemed like Santiago Pastorino that #67000 had a few implications

what do you mean? I guess you're talking about some discussion that I may have missed

nikomatsakis (Jan 07 2020 at 15:06, on Zulip):

yeah, perhaps, there was an issue, I'm trying to find it

oli (Jan 07 2020 at 15:07, on Zulip):

what does "Formalizing out parameters (or args passed by pointer because they are too large)" mean?

this is from the last all hands, we talked about teaching MIR about things like writing a value directly into the parent frame (and into fields of things no less)

nikomatsakis (Jan 07 2020 at 15:07, on Zulip):

I see

oli (Jan 07 2020 at 15:07, on Zulip):

I don't remember the details, but it got pretty funky around enum variants

nikomatsakis (Jan 07 2020 at 15:08, on Zulip):

one thing that I don't see on the list

nikomatsakis (Jan 07 2020 at 15:08, on Zulip):

would be modifying MIR to be more easily edited

nikomatsakis (Jan 07 2020 at 15:08, on Zulip):

e.g., convering from vectors and things identified by index

oli (Jan 07 2020 at 15:08, on Zulip):

basically all the NRVO stuff under https://paper.dropbox.com/doc/Topic-MIR-2.0-and-MIR-Optimizations--Ar_DezRvHY6zSzu1gCqSwicbAg-BwHR7kOhxDwL6vuAUoSTQ#:uid=104340020150096374938901&h2=NRVO-Discussion

nikomatsakis (Jan 07 2020 at 15:08, on Zulip):

into "linked lists" (perhaps threaded by index through a vector)

Santiago Pastorino (Jan 07 2020 at 15:08, on Zulip):

@nikomatsakis can you add that to the list maybe?

nikomatsakis (Jan 07 2020 at 15:09, on Zulip):

I don't remember the details, but it got pretty funky around enum variants

this makes me wonder again about trying to separate out "MIR for optimization" from "MIR for analysis" more clearly

nikomatsakis (Jan 07 2020 at 15:09, on Zulip):

actually the stuff about removing projections and so forth has the same question

oli (Jan 07 2020 at 15:09, on Zulip):

hmm right, we talked about this at the all hands, too. I thought that it was still not clear whether we'd want that or whether we'd want transactional changes

nikomatsakis (Jan 07 2020 at 15:09, on Zulip):

I don't really know what "transactional" means

nikomatsakis (Jan 07 2020 at 15:09, on Zulip):

it sounds like extra complexity

oli (Jan 07 2020 at 15:10, on Zulip):

well, like with databases

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

I mean I know what it means

oli (Jan 07 2020 at 15:10, on Zulip):

where you can specifiy an atomic change

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

right, I guess I am proposing a simpler variant

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

where we just make MIR easier to mutate

oli (Jan 07 2020 at 15:10, on Zulip):

right

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

and we write the code carefully :)

oli (Jan 07 2020 at 15:10, on Zulip):

heheh

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

regardless it seems like a good "first step"

nikomatsakis (Jan 07 2020 at 15:10, on Zulip):

that said, I guess MirPatch is some kind of transactional system?

nikomatsakis (Jan 07 2020 at 15:11, on Zulip):

but it always struck me as an elaborate workaround for the fact that MIR is a PITA to edit

oli (Jan 07 2020 at 15:11, on Zulip):

yea

nikomatsakis (Jan 07 2020 at 15:11, on Zulip):

I'm going to edit the hackmd slightly to break things into

Santiago Pastorino (Jan 07 2020 at 15:11, on Zulip):

yeah I've added that to the list because I'm not sure if what was proposed is not covered by MirPatch

nikomatsakis (Jan 07 2020 at 15:11, on Zulip):
nikomatsakis (Jan 07 2020 at 15:12, on Zulip):
oli (Jan 07 2020 at 15:12, on Zulip):

One thing that also came up is merging mir optimizations so not all of them repeat the entire visiting logic

Santiago Pastorino (Jan 07 2020 at 15:12, on Zulip):

@oli actually, what we did with the extra_statements, can't be done with MirPatch?

oli (Jan 07 2020 at 15:12, on Zulip):

yea but we didn't want to mingle improvements with reverts

Santiago Pastorino (Jan 07 2020 at 15:12, on Zulip):

right

nikomatsakis (Jan 07 2020 at 15:13, on Zulip):

this covers removing deref/field/etc as well as formalizing out parameters

nikomatsakis (Jan 07 2020 at 15:13, on Zulip):

One thing that also came up is merging mir optimizations so not all of them repeat the entire visiting logic

merging how exactly?

nikomatsakis (Jan 07 2020 at 15:13, on Zulip):

like, in some "automatic" way?

nikomatsakis (Jan 07 2020 at 15:14, on Zulip):

or writing a "meta patch"?

oli (Jan 07 2020 at 15:14, on Zulip):

yea, meta patch that merges them similar to how lints are merged

oli (Jan 07 2020 at 15:14, on Zulip):

so you walk and invoke methods on the pass depending on where you are instead of each pass walking the entire mir::Body

nikomatsakis (Jan 07 2020 at 15:15, on Zulip):

I guess this then touches on the transactional thing

nikomatsakis (Jan 07 2020 at 15:15, on Zulip):

since if you are making edits

nikomatsakis (Jan 07 2020 at 15:15, on Zulip):

it's potentially strange to be "editing" at the same time?

nikomatsakis (Jan 07 2020 at 15:15, on Zulip):

that said

nikomatsakis (Jan 07 2020 at 15:15, on Zulip):

a lot of compiler's I've seen distinguish peephole optimizations

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

from other sorts

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

and peephole optimizations are 'chained' in this way

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

since they (by definition) require only very local context and tend also to sometimes build on one another

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

side note:

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

MIR inlining has come up a few times recently

nikomatsakis (Jan 07 2020 at 15:16, on Zulip):

as being of particular importance

oli (Jan 07 2020 at 15:17, on Zulip):

yea, I think we're still not able to bootstrap with MIR inlining, but @Wesley Wiser has been working on getting rid of a few bugs relating to that

nikomatsakis (Jan 07 2020 at 15:18, on Zulip):

I think I would propose that we focus on "less dramatic stuff" still

If we were going to do anything more ambitious, I would think that simplifying projections might be it, and I still think the scheme I roughly described for that is probably best, but I don't really remember who I was talking with about it way back when

oli (Jan 07 2020 at 15:19, on Zulip):

Hmm... it now says "remove field from projections", but why?

nikomatsakis (Jan 07 2020 at 15:19, on Zulip):

(PS, I'm trying to edit hackmd to categorize and extend things)

oli (Jan 07 2020 at 15:19, on Zulip):

isn't field just an offset

nikomatsakis (Jan 07 2020 at 15:19, on Zulip):

Hmm... it now says "remove field from projections", but why?

well I think that was the most extreme version, I don't know that it makes any sense

nikomatsakis (Jan 07 2020 at 15:20, on Zulip):

I think the most extreme version would just .. not have "places" really, just local variables in some sense

oli (Jan 07 2020 at 15:20, on Zulip):

yea

oli (Jan 07 2020 at 15:20, on Zulip):

either all the way, or keep fields + const index together

oli (Jan 07 2020 at 15:21, on Zulip):

we may just want to collect statistics on this before we talk about the merit of either

nikomatsakis (Jan 07 2020 at 15:21, on Zulip):

so one thought

nikomatsakis (Jan 07 2020 at 15:21, on Zulip):

the main reason to do this change

nikomatsakis (Jan 07 2020 at 15:21, on Zulip):

is to make advanced optimizations easier

nikomatsakis (Jan 07 2020 at 15:21, on Zulip):

the challenge is that it makes borrowck harder and sort of interferes w/ stacked borrows

nikomatsakis (Jan 07 2020 at 15:21, on Zulip):

potentially anyway

nikomatsakis (Jan 07 2020 at 15:22, on Zulip):

what I was going to say is that you could do it by a "postprocessing" step

nikomatsakis (Jan 07 2020 at 15:22, on Zulip):

it doesn't solve the stacked borrows part of thing, but that's still .. somewhat WIP

nikomatsakis (Jan 07 2020 at 15:22, on Zulip):

i.e., you can easily imagine walking down MIR as a peephole transformation and replacing deref projections etc with temporaries of the kind I described

oli (Jan 07 2020 at 15:22, on Zulip):

right

nikomatsakis (Jan 07 2020 at 15:23, on Zulip):

this would enable the optimizations at least without blocking on this other question

oli (Jan 07 2020 at 15:23, on Zulip):

we could start out with adding such an optimization and moving it earlier and earlier until we can just remove the projection itself

nikomatsakis (Jan 07 2020 at 15:23, on Zulip):

@eddyb are you here?

nikomatsakis (Jan 07 2020 at 15:23, on Zulip):

we could start out with adding such an optimization and moving it earlier and earlier until we can just remove the projection itself

maybe -- or maybe we never remove it

nikomatsakis (Jan 07 2020 at 15:24, on Zulip):

though I think a scheme where we build up "complex projections" in some way is actually reasonably nice

nikomatsakis (Jan 07 2020 at 15:24, on Zulip):

but it is definitely moving MIR closer to optimization and further from the "ideal borrowck repr"

nikomatsakis (Jan 07 2020 at 15:24, on Zulip):

I guess I could imagine just having a LIR for optimization

nikomatsakis (Jan 07 2020 at 15:25, on Zulip):

but the compilation time or memory costs of that may not be worthwhile

oli (Jan 07 2020 at 15:25, on Zulip):

doesn't borrowck already have to handle all this because you can rewrite almost all logic where there are temporaries by introducing variables?

nikomatsakis (Jan 07 2020 at 15:25, on Zulip):

no, that is very different from borrowck's perpsective

nikomatsakis (Jan 07 2020 at 15:25, on Zulip):

I'm not sure what you mean by temporaries

nikomatsakis (Jan 07 2020 at 15:26, on Zulip):

but Places are designed to be .. almost exactly the kinds of path that borrowck understands, modulo reasoning about indices and equality

nikomatsakis (Jan 07 2020 at 15:26, on Zulip):

(also I think we should rename Place to Path, but I guess that's neither here nor there)

nikomatsakis (Jan 07 2020 at 15:26, on Zulip):

one thing I will say about borrowck though

oli (Jan 07 2020 at 15:26, on Zulip):

well 5 + 6 + 7 has a temporary local for tmp = 5 + 6 which is then added via tmp + 7, and you can write this in user code. I thought except for some drop rules from mir building the behaviour was also the same in mir borrowck no matter whether you have temporaries or user defined locals

nikomatsakis (Jan 07 2020 at 15:27, on Zulip):

yes, that's fine

nikomatsakis (Jan 07 2020 at 15:27, on Zulip):

and borrowck doesn't do any special reasoning about those

nikomatsakis (Jan 07 2020 at 15:27, on Zulip):

the behaviour was also the same in mir borrowck no matter whether you have temporaries or user defined locals

this is true -- but it can't be true for the temporaries we would be introducing for deref projections

nikomatsakis (Jan 07 2020 at 15:27, on Zulip):

let me give an example

nikomatsakis (Jan 07 2020 at 15:27, on Zulip):
let x = &mut (*foo).bar;
let y = &mut (*foo).baz;
nikomatsakis (Jan 07 2020 at 15:28, on Zulip):

this type- and borrow-checks today

nikomatsakis (Jan 07 2020 at 15:28, on Zulip):
let t0 = &mut *foo;
let x = &mut (*t0.bar);
let t1 = &mut *foo;
let x = &mut (*t1.bar);
nikomatsakis (Jan 07 2020 at 15:28, on Zulip):

this doesn't

oli (Jan 07 2020 at 15:28, on Zulip):

hm right

nikomatsakis (Jan 07 2020 at 15:28, on Zulip):

(not that introducing such a temporary makes all that much sense)

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

(in that specific example)

oli (Jan 07 2020 at 15:29, on Zulip):

yea but it's what the compiler would do

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

this is also the same problem for stacked borrows

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

yeah you get the idea

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

I mean now plausibly we could make borrowck smarter, and enable it to understand and accept that code

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

but it would be a pretty deep change

nikomatsakis (Jan 07 2020 at 15:29, on Zulip):

and it would have impact on stacked borrows etc

nikomatsakis (Jan 07 2020 at 15:30, on Zulip):

(and, if we went too far, even invalidate I think some of the logic in libstd)

nikomatsakis (Jan 07 2020 at 15:30, on Zulip):

which is why I was thinking that we would rather have some kind of "blessing" concept

nikomatsakis (Jan 07 2020 at 15:30, on Zulip):

where you desugar e.g. (*foo).bar into

nikomatsakis (Jan 07 2020 at 15:30, on Zulip):

(a) creating the "place value" and then (b) accessing the place value

nikomatsakis (Jan 07 2020 at 15:31, on Zulip):

and place values can get built piece by piece but are not considered a borrow, just an inert pointer, until they are either "loaded from" or "borrowed"

nikomatsakis (Jan 07 2020 at 15:31, on Zulip):

and the borrow checker kind of tracks the path that a place value comes from

oli (Jan 07 2020 at 15:32, on Zulip):

well... that's essentially what @ecstatic-morse suggested with Rvalue::DerefProjection where you still do this in one step, but you can't use a projection as the place that you deref

nikomatsakis (Jan 07 2020 at 15:32, on Zulip):

I don't think we can accept any restrictions

nikomatsakis (Jan 07 2020 at 15:32, on Zulip):

maybe I don't understand

nikomatsakis (Jan 07 2020 at 15:32, on Zulip):

but e.g. *(*foo.bar).baz etc is a valid path today

oli (Jan 07 2020 at 15:32, on Zulip):

so we'd have primitives that are just what we need to keep the current behaviour but stop allowing a projection to have multiple derefs in one projection list

oli (Jan 07 2020 at 15:33, on Zulip):

and borrowck gets that?

nikomatsakis (Jan 07 2020 at 15:33, on Zulip):

yes sure

oli (Jan 07 2020 at 15:33, on Zulip):

oic

oli (Jan 07 2020 at 15:33, on Zulip):

wow

nikomatsakis (Jan 07 2020 at 15:33, on Zulip):

like I said, a Place is designed to be exactly the kind of path borrowck understands, I don't really think we can simpify it

oli (Jan 07 2020 at 15:33, on Zulip):

ok

nikomatsakis (Jan 07 2020 at 15:33, on Zulip):

( but we could build it up piece by piece )

nikomatsakis (Jan 07 2020 at 15:34, on Zulip):

and that "lowers" (for optimization purposes) into pointer manipulation

oli (Jan 07 2020 at 15:34, on Zulip):

yea makes sense

oli (Jan 07 2020 at 15:34, on Zulip):

but stacked borrows would still choke on it

oli (Jan 07 2020 at 15:34, on Zulip):

meaning we couldn't have miri run optimized code anymore

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

well

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

that depends

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

i.e., if we had some notion of "blessing" a place value

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

maybe that is retained in the MIR but optimized out to a no-op at llvm generation time

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

I guess all I mean is

nikomatsakis (Jan 07 2020 at 15:35, on Zulip):

the & that the user wrote might be special

nikomatsakis (Jan 07 2020 at 15:36, on Zulip):

and distinguished from the pointer manipulation that goes into constructing the path

nikomatsakis (Jan 07 2020 at 15:36, on Zulip):

and stacked borrows can likely still see that

oli (Jan 07 2020 at 15:36, on Zulip):

right

nikomatsakis (Jan 07 2020 at 15:36, on Zulip):

meaning we couldn't have miri run optimized code anymore

but yes this is why I think it takes us some design to get this right

nikomatsakis (Jan 07 2020 at 15:36, on Zulip):

tbh I'm finding the notation a bit hard to express, which is annoying

nikomatsakis (Jan 07 2020 at 15:36, on Zulip):

part of it is the C legacy of *foo.bar meaning "load value from" and &*foo.bar meaning "take address of"

nikomatsakis (Jan 07 2020 at 15:37, on Zulip):

it makes it confusing to keep track of when a real load occurs :)

nikomatsakis (Jan 07 2020 at 15:37, on Zulip):

I was going to try to write out some example and kept getting tripped up :P

oli (Jan 07 2020 at 15:38, on Zulip):

yea, having an Rvalue::RefProject that doesn't actually have a Deref in it is basically this idea of having a reference and just offsetting the pointer

nikomatsakis (Jan 07 2020 at 15:39, on Zulip):

but anyway the high-level idea would be that we have "place temporaries" that get defined by a limited set of operations and which cannot be "used" by ordinary things; you have to either "load" from them or borrow them.

nikomatsakis (Jan 07 2020 at 15:39, on Zulip):

They'd probably be affine - i.e., consumed at most once

nikomatsakis (Jan 07 2020 at 15:39, on Zulip):

And those "load" and "borrow" operations are where stacked borrows would kick in I guess

nikomatsakis (Jan 07 2020 at 15:40, on Zulip):

well I mean we have to define how to handle them in stacked borrows, they'd be part of it, but those load/borrow operations would correspond to some of the stacked borrows changes that occur today

nikomatsakis (Jan 07 2020 at 15:40, on Zulip):

I forget how much @RalfJ and I talked about this

nikomatsakis (Jan 07 2020 at 15:43, on Zulip):

I guess then that x = &*(*tmp.bar).baz would be something like

P0 = LOAD(tmp.bar) // P0 is a "place temporary", meaning that it is a pointer effectively
P1 = LOAD(P0.baz)
X = &P1

and borrowck would understand that (e.g.) tmp.bar was not borrowed

nikomatsakis (Jan 07 2020 at 15:43, on Zulip):

in some ways this might simplify borrowck, since right now I think we have to figure out which loads and other accesses occur as part of a borrow.. maybe? that maybe just falls out

nikomatsakis (Jan 07 2020 at 15:43, on Zulip):

anyway, I think we should table these details and turn back to the higher level questions?

nikomatsakis (Jan 07 2020 at 15:43, on Zulip):

(I'm open to other schemes, just want to emphasize, this is the only one I've thought of though)

Santiago Pastorino (Jan 07 2020 at 15:45, on Zulip):

anyway, I think we should table these details and turn back to the higher level questions?

I was wondering exactly the same, maybe we should lay out a higher level plan with at least some first steps and we can organize more meetings to define some of the missing details if needed

nikomatsakis (Jan 07 2020 at 15:45, on Zulip):

yeah so all of these concerns is what motivated me to think:

nikomatsakis (Jan 07 2020 at 15:45, on Zulip):

focus on the lower-hanging fruit of optimizing MIR and making it more expressive easier to edit

nikomatsakis (Jan 07 2020 at 15:46, on Zulip):

and if we needed to eliminate deref to make it tractable, do it by local rewriting before the optimization

nikomatsakis (Jan 07 2020 at 15:46, on Zulip):

(that will mess up stacked borrows tho)

nikomatsakis (Jan 07 2020 at 15:46, on Zulip):

(though there may be a desugaring involving &raw that is relatively harmless?)

oli (Jan 07 2020 at 15:46, on Zulip):

ooh

oli (Jan 07 2020 at 15:46, on Zulip):

that's an idea

nikomatsakis (Jan 07 2020 at 15:46, on Zulip):

I don't think that works so well for borrow check

nikomatsakis (Jan 07 2020 at 15:47, on Zulip):

but it might work for stacked borrows

Santiago Pastorino (Jan 07 2020 at 15:48, on Zulip):

btw, just pure ignorance, how far are we from having stacked borrows in code? I haven't followed that that much

nikomatsakis (Jan 07 2020 at 15:48, on Zulip):

well, there's a prototype that works, but

nikomatsakis (Jan 07 2020 at 15:49, on Zulip):

(a) it works on miri only of course

nikomatsakis (Jan 07 2020 at 15:49, on Zulip):

(b) by "works" I mean that it runs the rules and detects violations

nikomatsakis (Jan 07 2020 at 15:49, on Zulip):

(c) but the rules themselves are not fully agreed to nor widely understood :)

Santiago Pastorino (Jan 07 2020 at 15:49, on Zulip):

ok

nikomatsakis (Jan 07 2020 at 15:49, on Zulip):

(d) and in particular lots of extant code, including code in libstd, gets errors, and we haven't decided whether all of those things ought to be errors

nikomatsakis (Jan 07 2020 at 15:50, on Zulip):

still, I think it is pretty widely recognized as the most promising start we have towards a set of workable rules

Santiago Pastorino (Jan 07 2020 at 15:50, on Zulip):

:+1:

Santiago Pastorino (Jan 07 2020 at 15:50, on Zulip):

so we have 10 more minutes ...

Santiago Pastorino (Jan 07 2020 at 15:51, on Zulip):

should we define some next steps?

Santiago Pastorino (Jan 07 2020 at 15:52, on Zulip):

or I mean, what would be best to define in this last minutes?

nikomatsakis (Jan 07 2020 at 15:52, on Zulip):

seems like it to me

nikomatsakis (Jan 07 2020 at 15:52, on Zulip):

also worth noting: next all hands, presuming it happens :), will be mid March

nikomatsakis (Jan 07 2020 at 15:52, on Zulip):

so that is a time frame to keep in mind

Santiago Pastorino (Jan 07 2020 at 15:52, on Zulip):

yep

oli (Jan 07 2020 at 15:52, on Zulip):

I won't be there

nikomatsakis (Jan 07 2020 at 15:52, on Zulip):

:'(

Santiago Pastorino (Jan 07 2020 at 15:52, on Zulip):

ouch :(

nikomatsakis (Jan 07 2020 at 15:52, on Zulip):

still, I feel like talking over deref/index and how to adjust borrowck would be a topic that might be well covered in person

oli (Jan 07 2020 at 15:52, on Zulip):

Need to be back in germany on saturday

Santiago Pastorino (Jan 07 2020 at 15:53, on Zulip):

you didn't figure out trains I guess?

nikomatsakis (Jan 07 2020 at 15:53, on Zulip):

(you could leave early or something? but ok)

Santiago Pastorino (Jan 07 2020 at 15:53, on Zulip):

Need to be back in germany on saturday

ahh

oli (Jan 07 2020 at 15:53, on Zulip):

yea, I could just be there for a few days I guess

Santiago Pastorino (Jan 07 2020 at 15:53, on Zulip):

yea, I could just be there for a few days I guess

do it :)

Santiago Pastorino (Jan 07 2020 at 15:54, on Zulip):

still, I feel like talking over deref/index and how to adjust borrowck would be a topic that might be well covered in person

:+1:

nikomatsakis (Jan 07 2020 at 15:54, on Zulip):

I'm curious @oli what you think about making MIR more ergonomic to edit

nikomatsakis (Jan 07 2020 at 15:54, on Zulip):

maybe we need to get more detailed about what that would mean

nikomatsakis (Jan 07 2020 at 15:54, on Zulip):

as a start, we could make basic block indices persistent :)

oli (Jan 07 2020 at 15:54, on Zulip):

Yea, I'm worried that the medicine is worse than the illness

nikomatsakis (Jan 07 2020 at 15:54, on Zulip):

I don't know what that means in this context :)

oli (Jan 07 2020 at 15:55, on Zulip):

well... the linked list stuff sounds rather easy to mess up

nikomatsakis (Jan 07 2020 at 15:55, on Zulip):

interesting. I was thinking the opposite.

oli (Jan 07 2020 at 15:55, on Zulip):

so we'd need a good API around it... which may just make ppl run index lists on their side again

nikomatsakis (Jan 07 2020 at 15:55, on Zulip):

I guess maybe the question is what it means to "mess up"

Wesley Wiser (Jan 07 2020 at 15:55, on Zulip):

/me is following along on mobile but probably going to lose service in a minute.

oli (Jan 07 2020 at 15:55, on Zulip):

yea, maybe I just can't imagine how it'd look

nikomatsakis (Jan 07 2020 at 15:56, on Zulip):

probably what makes the most sense is to look at what things optimizations are doing now

nikomatsakis (Jan 07 2020 at 15:56, on Zulip):

and also to compare, I think, against the setup of cranelift

nikomatsakis (Jan 07 2020 at 15:56, on Zulip):

but jsut starting with: basic block ids are not indices into a vector but rather keys into a hashmap

Wesley Wiser (Jan 07 2020 at 15:56, on Zulip):

The inliner is kind of the biggest stress test now since it adjusts locals/places, statement indexes, etc

nikomatsakis (Jan 07 2020 at 15:57, on Zulip):

yeah, it does a lot of random things, although some of them it sort of has to do

nikomatsakis (Jan 07 2020 at 15:57, on Zulip):

but I agree it'd be a good candidate to examine

nikomatsakis (Jan 07 2020 at 15:57, on Zulip):

also the drop elaboration?

nikomatsakis (Jan 07 2020 at 16:01, on Zulip):

welp I have to run to another meeting; seems like no firm conclusions, but good to chat about things?

Santiago Pastorino (Jan 07 2020 at 16:01, on Zulip):

yeah

Santiago Pastorino (Jan 07 2020 at 16:01, on Zulip):

I guess we can conclude something async?

bjorn3 (Jan 07 2020 at 16:03, on Zulip):

and also to compare, I think, against the setup of cranelift

cg_clif with mir opt and my clif stack opt pass is a bit faster than cg_llvm without optimizations for the runtime of one benchmark.

nikomatsakis (Jan 07 2020 at 16:07, on Zulip):

I'm not sure I understand what that means--

nikomatsakis (Jan 07 2020 at 16:07, on Zulip):

I meant more like "it'd be good to compare how the data structures are setup"

bjorn3 (Jan 07 2020 at 16:08, on Zulip):

I though you meant performance.

nikomatsakis (Jan 07 2020 at 16:10, on Zulip):

Ah ok :) good to know though!

bjorn3 (Jan 07 2020 at 16:11, on Zulip):

Cranelift separates the data structure containing all instructions combined with arguments (DataFlowGraph) and the data structure containing the actual place an instruction exists (Layout)

bjorn3 (Jan 07 2020 at 16:13, on Zulip):

When an instruction argument would cause the instruction enum to become larger, then it is often stored in a side table instead with the instruction pointing to the index.

RalfJ (Jan 07 2020 at 20:23, on Zulip):

@nikomatsakis I dont remember talking about how this interacts with Stacked Borrows at all^^

RalfJ (Jan 07 2020 at 20:23, on Zulip):

but the plan sounds reasonable. it's already the case now that & doesn't do anything, just Retag(place) does. so it seems all we have to do is make sure that retag insertion can distinguish user-written & from those introduced by lowering.

nagisa (Jan 11 2020 at 20:02, on Zulip):

e.g., convering from vectors and things identified by index

Thanks for mentioning this.

Circling back around mutation: I consider something transactional a requirement. This is what enables easy estimation of value in mutation.

nagisa (Jan 11 2020 at 20:03, on Zulip):

This is especially relevant in context of peephole optimisations. LLVM has a some truoble with certain peephole "deoptimisations" that ought to enable further peephole optimisations. Having something transactional allows to do pretty much whatever in between beginning and figuring out whether it should be applied at all.

nagisa (Jan 11 2020 at 20:05, on Zulip):

It perhaps even allows exploring "alternatives".

nagisa (Jan 11 2020 at 20:05, on Zulip):

though I think another thing we should do is figure out how optimisation-oriented we want to make MIR.

nagisa (Jan 11 2020 at 20:06, on Zulip):

If all we care about is some inlining, basic const propagation and basic instruction combination, then perhaps doing too much is plain counterproductive.

nagisa (Jan 11 2020 at 20:09, on Zulip):

FWIW I’m still thinking if I should make time to go to all hands. This is basically the only topic I have anything to say about

Last update: Apr 04 2020 at 23:40UTC