Stream: t-compiler

Topic: design meeting 2020-04-03 compiler-team#257


nikomatsakis (Apr 03 2020 at 13:51, on Zulip):

Dear @T-compiler/meeting -- design meeting in 9 minutes on this topic.

nikomatsakis (Apr 03 2020 at 13:52, on Zulip):

Today's topic: Cranelift backend for rustc compiler-team#257

Details in this hackmd (thanks @bjorn3)

nikomatsakis (Apr 03 2020 at 13:53, on Zulip):

To start....

Announcements

eddyb (Apr 03 2020 at 13:53, on Zulip):

quick note: the submodule question will become a subtree question soon so we should adjust to that (which I think is more favorable than submodules anyway)

nikomatsakis (Apr 03 2020 at 13:53, on Zulip):
eddyb (Apr 03 2020 at 13:53, on Zulip):

(speak of the devil)

centril (Apr 03 2020 at 13:54, on Zulip):

Maybe we should think of some evaluation plan for the subtree thing

centril (Apr 03 2020 at 13:54, on Zulip):

like how much time do we wait until we apply this to Miri?

simulacrum (Apr 03 2020 at 13:54, on Zulip):

I think we should not derail this meeting with that :)

centril (Apr 03 2020 at 13:54, on Zulip):

1 month maybe?

pnkfelix (Apr 03 2020 at 13:54, on Zulip):

i even just noticed at the end of the hackmd regarding cg_clif it asks "should this be a submodule or <monorepo>"

pnkfelix (Apr 03 2020 at 13:55, on Zulip):

so arguably we can spend a little time talking about our general policy here

centril (Apr 03 2020 at 13:55, on Zulip):

@simulacrum fair point; I'll add comments to the MCP issue instead

pnkfelix (Apr 03 2020 at 13:55, on Zulip):

(but it can perhaps wait until the end.)

simulacrum (Apr 03 2020 at 13:55, on Zulip):

I think whether monorepo or submodule/subtree is a good question to address, but not "should it be subtree or submodule"

simulacrum (Apr 03 2020 at 13:56, on Zulip):

i.e. IMO subtree or submodule is an implementation detail, though an important one, and we should either do one or the other (globally, most likely)

pnkfelix (Apr 03 2020 at 13:56, on Zulip):

I mostly agree with @simulacrum , but the the differences between submodule and subtree may be relevant to the decision

eddyb (Apr 03 2020 at 13:56, on Zulip):

eddyb said:

quick note: the submodule question will become a subtree question soon so we should adjust to that (which I think is more favorable than submodules anyway)

that's what I was saying here heh

pnkfelix (Apr 03 2020 at 13:56, on Zulip):

e.g. i'd hate for us to say "it has to be in-tree because submodule is so painful", and then later determine we'll be switching to subtree

pnkfelix (Apr 03 2020 at 13:57, on Zulip):

eddyb said:

eddyb said:

quick note: the submodule question will become a subtree question soon so we should adjust to that (which I think is more favorable than submodules anyway)

that's what I was saying here heh

ah that was definitely not clear to me

eddyb (Apr 03 2020 at 13:57, on Zulip):

yeah my assumption was that the subtree MCP would go through

pnkfelix (Apr 03 2020 at 13:57, on Zulip):

and that phrasing presupposes the switch

pnkfelix (Apr 03 2020 at 13:57, on Zulip):

right

centril (Apr 03 2020 at 13:58, on Zulip):

Although I think there are good arguments for "a codegen backend is different, its not a tool, it should be in tree"

pnkfelix (Apr 03 2020 at 13:58, on Zulip):

anyway, as long as everyone is aware that we might switch to subtree, that should be enough to inform subsequent discussion

simulacrum (Apr 03 2020 at 13:58, on Zulip):

I do think it's highly likely we'll be switching to something like subtrees soon, and evaluating this can be done on the basis of a positive decision there. (Whether that's subtree or some other similar tooling, I think it's clear we want something like it).

eddyb (Apr 03 2020 at 13:59, on Zulip):

my opinion is we should try to have cg_clif as a subtree for a while and only move upstream at some "feature-parity" milestone or w/e

eddyb (Apr 03 2020 at 13:59, on Zulip):

just to facilitate development if @bjorn3 primarily prefers out-of-tree

centril (Apr 03 2020 at 13:59, on Zulip):

Yeah I agree; directly into tree is a bit hasty :slight_smile:

bjorn3 (Apr 03 2020 at 13:59, on Zulip):

Sorry for being late.

pnkfelix (Apr 03 2020 at 14:00, on Zulip):

you're not late.

pnkfelix (Apr 03 2020 at 14:00, on Zulip):

we're absurdly early

bjorn3 (Apr 03 2020 at 14:00, on Zulip):

Now I notice :)

Jason Williams (Apr 03 2020 at 14:00, on Zulip):

lurking but hello everyone

eddyb (Apr 03 2020 at 14:01, on Zulip):

if things had gone differently (around the time of the rustc_codegen_ssa split) we might've had it in-tree and father along by now but we didn't and @bjorn3 has done a lot of work on this so I think we should try to avoid hindering that until circumstances change

nikomatsakis (Apr 03 2020 at 14:02, on Zulip):

Hey @T-compiler/meeting ... design meeting starting now. There's already been some pre-chatter about modules/subtrees/etc. Let's give a few minutes for folks to gather. Any further announcements?

nikomatsakis (Apr 03 2020 at 14:02, on Zulip):
nikomatsakis (Apr 03 2020 at 14:05, on Zulip):

Shall we get started?

centril (Apr 03 2020 at 14:05, on Zulip):

Some potential additional design questions for the agenda:

nikomatsakis (Apr 03 2020 at 14:05, on Zulip):

Can you add those to the end of the hackmd?

centril (Apr 03 2020 at 14:06, on Zulip):

sure

nikomatsakis (Apr 03 2020 at 14:06, on Zulip):

I guess let's start with a brief overview of the cranelift backend, history / status? There's a good detailed rundown of the bugs and things in the hackmd, but I figure it's good to bring people a bit up to speed

nikomatsakis (Apr 03 2020 at 14:07, on Zulip):

(I for one had a few questions about the reference to "JIT" compilation, for example)

nikomatsakis (Apr 03 2020 at 14:07, on Zulip):

@bjorn3 do you want to talk a bit about that?

nikomatsakis (Apr 03 2020 at 14:08, on Zulip):

(I guess I'm thinking of some of the stuff that's in the "motivation")

nikomatsakis (Apr 03 2020 at 14:08, on Zulip):

Cranelift has the potential to improve compilation time, as it is optimized for compilation time as opposed to being optimized for good optimizations like LLVM. Over the course of the past ~1.5 year I have been working on a Cranelift based codegen backend for rustc (rustc_codegen_cranelift or cg_clif for short). It is currently complete enough to compile many programs. While there are cases where LLVM is faster, Cranelift is already faster than LLVM in many cases.

nikomatsakis (Apr 03 2020 at 14:09, on Zulip):

Basically the main goal remains having an alternative backend that could be used for faster, non-optimized builds?

bjorn3 (Apr 03 2020 at 14:09, on Zulip):

Yes

nikomatsakis (Apr 03 2020 at 14:10, on Zulip):

Can you say a bit about how it's loaded and built today? I have a vague understanding but I'd like to understand it a bit better. What I know is roughly

nikomatsakis (Apr 03 2020 at 14:10, on Zulip):
eddyb (Apr 03 2020 at 14:11, on Zulip):

I'm not sure how much we've removed, we used to have a way to use an alternative codegen backend for emscripten because it needed an older (modified) LLVM

bjorn3 (Apr 03 2020 at 14:11, on Zulip):

It is build as a normal dylib. When you pass -Zcodegen-backend=/path/to/dylib to rustc, it will dlopen the specified dylib and call __rustc_codegen_backend, which returns a Box<dyn CodegenBackend>

eddyb (Apr 03 2020 at 14:11, on Zulip):

and it relied on loading dylibs from the sysroot (or alternatively, a full path to a dylib)

eddyb (Apr 03 2020 at 14:11, on Zulip):

so we still have the functionality then, makes sense

centril (Apr 03 2020 at 14:11, on Zulip):

For me, another motivation is independence from LLVM and their goals (which tend towards C++'s needs)

bjorn3 (Apr 03 2020 at 14:12, on Zulip):

@eddyb I am not sure if the sysroot part still works, but the full path version is what I use.

nikomatsakis (Apr 03 2020 at 14:12, on Zulip):

OK. That's helpful.

Jason Williams (Apr 03 2020 at 14:13, on Zulip):

@bjorn3 are you still the only person working on this backend?

bjorn3 (Apr 03 2020 at 14:13, on Zulip):

Yes

eddyb (Apr 03 2020 at 14:13, on Zulip):

and separately, rustc_codegen_ssa was an attempt years ago at creating a shared API that both LLVM and Cranelift can implement to build some low-level SSA IR (with load/store for memory accesses) to codegen MIR into

bjorn3 (Apr 03 2020 at 14:13, on Zulip):

So far I have only received a few small pull requests

nikomatsakis (Apr 03 2020 at 14:14, on Zulip):

So I guess the current status is that things 'mostly work' but there's a number of missing features, partly (mostly?) because of limitations of cranelift, right?

eddyb (Apr 03 2020 at 14:14, on Zulip):

the rustc_codegen_ssa effort was started by @dmerigoux and later @bjorn3 improved it further, IIRC

bjorn3 (Apr 03 2020 at 14:14, on Zulip):

I use some of the parts of rustc_codegen_ssa like the linker code, but the the function builder part is still too much tied to LLVM.

bjorn3 (Apr 03 2020 at 14:14, on Zulip):

nikomatsakis said:

So I guess the current status is that things 'mostly work' but there's a number of missing features, partly (mostly?) because of limitations of cranelift, right?

Yes

eddyb (Apr 03 2020 at 14:15, on Zulip):

bjorn3 said:

I use some of the parts of rustc_codegen_ssa like the linker code, but the the function builder part is still too much tied to LLVM.

oh we should be fixing those, maybe we should do a better job at tracking what's too LLVM-specific

nikomatsakis (Apr 03 2020 at 14:15, on Zulip):

OK. I'd like to hear a bit about the motivations to bring things in tree -- what problems are we hoping to fix :) (seems like some are obvious, but I figure good to state them explicitly)

nikomatsakis (Apr 03 2020 at 14:16, on Zulip):

It seems like one of them is probably building a bigger maintainer base :)

bjorn3 (Apr 03 2020 at 14:16, on Zulip):

That would be nice :)

nikomatsakis (Apr 03 2020 at 14:16, on Zulip):

And maybe getting more serious about the "backend-independent parts" of the code?

nikomatsakis (Apr 03 2020 at 14:16, on Zulip):

(i.e., what @eddyb just said)

Jason Williams (Apr 03 2020 at 14:17, on Zulip):

Sorry if this is offtopic, but does having a cranelift backend for development help with Debugging symbols/information?
This is a major painpoint for many users right now? I hear some of it is to do with LLVM optimising away too much

eddyb (Apr 03 2020 at 14:18, on Zulip):

LLVM should be optimizing away none of it if optimizations are off

eddyb (Apr 03 2020 at 14:18, on Zulip):

Cranelift doesn't really have optimizations AFAIK the way LLVM does

bjorn3 (Apr 03 2020 at 14:18, on Zulip):

@Jason Williams Line debuginfo is supported, though things like is_stmt are not set. Other debuginfo is not implemented yet

eddyb (Apr 03 2020 at 14:18, on Zulip):

long-term, maybe Cranelift can be better than LLVM by providing debuginfo-preserving optimizations, but I don't think it's that relevant right now

Jason Williams (Apr 03 2020 at 14:19, on Zulip):

ok thanks

bjorn3 (Apr 03 2020 at 14:19, on Zulip):

Cranelift has DCE, LICM (broken with jumptables) and a few other simple optimizations

Wesley Wiser (Apr 03 2020 at 14:19, on Zulip):

(Some of the debug complains I've seen might be specific to LLVM's support for CodeView/pdb on Windows)

bjorn3 (Apr 03 2020 at 14:20, on Zulip):

CodeView/pdb support is not implemented in cg_clif. As far as I know there is no writer crate for it.

nikomatsakis (Apr 03 2020 at 14:21, on Zulip):

I guess the meta question that I'm thinking about is what our "overall strategy" is around alternative backends. Like, how much do we want to prioritize this, relative to other goals? Maybe that's not something we can decide in this meeting.

My sense though is that it's a "background task", that we'd like to support "increasingly well", but not a "first class" goal that we really want to pour total energy into.

nikomatsakis (Apr 03 2020 at 14:21, on Zulip):

I'm thinking about the first "key design question" raised in the hackmd, in particular:

Wesley Wiser (Apr 03 2020 at 14:22, on Zulip):

@bjorn3 Do you find that there's a lot of churn on the parts of rustc you integrate with? How painful are rebases on top of the latest rustc usually? Might be another reason to do something in-tree...

centril (Apr 03 2020 at 14:22, on Zulip):

My sense though is that it's a "background task", that we'd like to support "increasingly well", but not a "first class" goal that we really want to pour total energy into.

I think that makes sense in terms of work hours; but personally I do think that when problems are created for the cg_clif backend, we should prioritize cg_clif highly

pnkfelix (Apr 03 2020 at 14:23, on Zulip):

It would interesting to know how the answer to the "in tree" question affects the "broadening the contributor set" goal

pnkfelix (Apr 03 2020 at 14:23, on Zulip):

I could imagine it helping or hurting

bjorn3 (Apr 03 2020 at 14:23, on Zulip):

@Wesley Wiser There is not that much churn. Most changes are simple search-replace fixes. There are rarely any changes that need significant fixes

nikomatsakis (Apr 03 2020 at 14:24, on Zulip):

Maybe it's useful to enumerate some of the "variables"? I think we have a good start in the document already. I'm thinking of:

eddyb (Apr 03 2020 at 14:25, on Zulip):

git subtree would give us the ability to change the in-tree version as we do breaking changes

eddyb (Apr 03 2020 at 14:25, on Zulip):

and then the separate repository can get sync'd from that

nikomatsakis (Apr 03 2020 at 14:25, on Zulip):

we have a few existing models to build from, I guess:

and I'm wondering which seems to "fit best"

bjorn3 (Apr 03 2020 at 14:25, on Zulip):

I prefer subtree.

centril (Apr 03 2020 at 14:25, on Zulip):

do test failures block CI?

We could solve this with // ignore-cranelift-backend

nikomatsakis (Apr 03 2020 at 14:26, on Zulip):

OK, it sounds like this is roughly "external tool" integration

pnkfelix (Apr 03 2020 at 14:26, on Zulip):

yeah, at least for the initial stages

nikomatsakis (Apr 03 2020 at 14:26, on Zulip):

But I guess that is the next question -- should we be running tests? (Maybe not yet?)

centril (Apr 03 2020 at 14:26, on Zulip):

@bjorn3 would you like to see it move into tree in maybe 1.5 years or so though?

bjorn3 (Apr 03 2020 at 14:26, on Zulip):

For LLVM only tests // only-llvm-backend would be nice.

pnkfelix (Apr 03 2020 at 14:26, on Zulip):

Maybe we should integrate support for running tests easily into x.py, but not gate CI on it?

nikomatsakis (Apr 03 2020 at 14:27, on Zulip):

I like that, to start

centril (Apr 03 2020 at 14:27, on Zulip):

I think we can reasonably gate in maybe 1 month or so and ignore the relevant tests

bjorn3 (Apr 03 2020 at 14:27, on Zulip):

centril said:

bjorn3 would you like to see it move into tree in maybe 1.5 years or so though?

I don't know: https://internals.rust-lang.org/t/experience-report-contributing-to-rust-lang-rust/12012/45

centril (Apr 03 2020 at 14:28, on Zulip):

I would like to be informed of in what the delta in the tests are in terms of support, and when a new feature causes problems for the cranelift backend

nikomatsakis (Apr 03 2020 at 14:28, on Zulip):

Hmm, let's not worry about 1.5 years from now. I personally think this question will be informed by the developments about library-ification and the like.

centril (Apr 03 2020 at 14:28, on Zulip):

Sure, let's not :slight_smile:

centril (Apr 03 2020 at 14:29, on Zulip):

It seems clear we're not moving into tree now at least

nikomatsakis (Apr 03 2020 at 14:29, on Zulip):

It seems like so far we've sketched out:

centril (Apr 03 2020 at 14:29, on Zulip):

Since no one is arguing for that

nikomatsakis (Apr 03 2020 at 14:29, on Zulip):

I want to double-check: are we gating on it building? That seems like it won't be a big hurdle, based on what @bjorn3 said

centril (Apr 03 2020 at 14:29, on Zulip):

I think we should personally, with opt-outs in tests

pnkfelix (Apr 03 2020 at 14:29, on Zulip):

wait, does "in tree" include `git subtree" ?

pnkfelix (Apr 03 2020 at 14:30, on Zulip):

I guess it does

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

oops sorry

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

I meant "git subtree"

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

let me edit

centril (Apr 03 2020 at 14:30, on Zulip):

@pnkfelix in-tree means not subtree/submodule

pnkfelix (Apr 03 2020 at 14:30, on Zulip):

okay well then that's not what @bjorn3 asked for

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

yeah, I edited

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

@bjorn3 feel free to withdraw your :heart: emoji if that changes your opinion

nikomatsakis (Apr 03 2020 at 14:30, on Zulip):

but I think it was what you were saying :)

bjorn3 (Apr 03 2020 at 14:31, on Zulip):

Yeah, I assumed you meant subtree with in-tree.

nikomatsakis (Apr 03 2020 at 14:31, on Zulip):

One of the questions that comes up is "who will sync the subtree"

nikomatsakis (Apr 03 2020 at 14:31, on Zulip):

I'm assuming the answer is @bjorn3 or other people working on the backend

centril (Apr 03 2020 at 14:32, on Zulip):

with Clippy it would be the Clippy maintainers

bjorn3 (Apr 03 2020 at 14:32, on Zulip):

How frequently should the syncing to rust-lang/rust be?

pnkfelix (Apr 03 2020 at 14:32, on Zulip):

we don't know?

Wesley Wiser (Apr 03 2020 at 14:33, on Zulip):

If you're not hitting a lot of issues now doing rebases rustups, it probably doesn't need to be that frequent.

bjorn3 (Apr 03 2020 at 14:33, on Zulip):

I am not doing rebases. I just add a rustup commit. (cg_clif is not a fork of the rust repo)

centril (Apr 03 2020 at 14:34, on Zulip):

with the subtrree thing, if people break the cranelift backend, then they have to fix it in their PR

Jason Williams (Apr 03 2020 at 14:34, on Zulip):

Would the PR fail if someone updated the subtree and it it doesn't build?

bjorn3 (Apr 03 2020 at 14:34, on Zulip):

Relatively big rustup commit: https://github.com/bjorn3/rustc_codegen_cranelift/commit/ac1c5d69544450d30785d001224f7233da48cbda
More normal rustup commit: https://github.com/bjorn3/rustc_codegen_cranelift/commit/786c7d8d8ce3a21a394404c41a01a666c26071f3

oli (Apr 03 2020 at 14:35, on Zulip):

subtree updates are just regular PRs

centril (Apr 03 2020 at 14:35, on Zulip):

@Jason Williams it should if we gate on cranelift

oli (Apr 03 2020 at 14:35, on Zulip):

so yes, they would fail if the update isn't compatible with the rest

nikomatsakis (Apr 03 2020 at 14:37, on Zulip):

OK, so, if the module is a git subtree, we're saving @bjorn3 the work of rebasing, but that's not that much. We're adding the ability to run tests, which is relatively easy for us to do, but if we don't gate CI on it, that updating will still have to be done by @bjorn3 or other cranelift-backend maintainers.

nikomatsakis (Apr 03 2020 at 14:37, on Zulip):

I'm trying to think about the concrete benefits here

centril (Apr 03 2020 at 14:38, on Zulip):

we're not gating CI on it?

nikomatsakis (Apr 03 2020 at 14:38, on Zulip):

I am also thinking a bit about the "commitment and maintainance" -- I don't think we're ready to take on a "high commitment" thing, but I think doing support is good. Some other steps we could consider are creating an experimental working group, i.e., a zulip stream to talk about the development

centril (Apr 03 2020 at 14:38, on Zulip):

I thought we were, with an opt-out mechanism for tests

pnkfelix (Apr 03 2020 at 14:38, on Zulip):

centril said:

we're not gating CI on it?

this was a question up above

nikomatsakis (Apr 03 2020 at 14:38, on Zulip):

Well, that wasn't in my list, let's ask? Do we want to gate CI on it.

pnkfelix (Apr 03 2020 at 14:38, on Zulip):

I had proposed making it easy to opt-in to run the tests via x.py, but not making it the default nor gating CI on it

pnkfelix (Apr 03 2020 at 14:38, on Zulip):

at least initially

nikomatsakis (Apr 03 2020 at 14:38, on Zulip):

(in particular, having it as an active WG might help to get folks to drop in and offer to help)

nikomatsakis (Apr 03 2020 at 14:39, on Zulip):

Yeah, let's figure out the test question. (I guess the other variable is distribution -- but I think we're pretty clearly not ready to be distributing, right?)

centril (Apr 03 2020 at 14:39, on Zulip):

I'd prefer to catch problems around e.g. unsized locals and whatnot early in CI and make it easy to grep for what tests work and don't

bjorn3 (Apr 03 2020 at 14:40, on Zulip):

distributing as nightly only component is possible given that many programs work

pnkfelix (Apr 03 2020 at 14:40, on Zulip):

I'd prefer not to gate CI on it until we have a firmer commitment to shipping it

bjorn3 (Apr 03 2020 at 14:40, on Zulip):

https://github.com/bjorn3/rustc_codegen_cranelift/issues/247

nikomatsakis (Apr 03 2020 at 14:41, on Zulip):

Implications of gating:

simulacrum (Apr 03 2020 at 14:42, on Zulip):

I know compare-mode=nll was/is super painful because it's not on by default and (roughly) doubles test time, and this seems like we'd at least initially have even more tests affected?

centril (Apr 03 2020 at 14:42, on Zulip):

@pnkfelix if we do that, should we revisit at some point?

pnkfelix (Apr 03 2020 at 14:42, on Zulip):

of course I would want to revisit it

pnkfelix (Apr 03 2020 at 14:42, on Zulip):

namely, once the feature set is more filled out

simulacrum (Apr 03 2020 at 14:42, on Zulip):

so I personally would rather not gate until we have parity etc

centril (Apr 03 2020 at 14:42, on Zulip):

sure, but like in some scheduled time :slight_smile:

nikomatsakis (Apr 03 2020 at 14:42, on Zulip):

That was a concern of mine, I should've added it -- CI time

pnkfelix (Apr 03 2020 at 14:42, on Zulip):

and we can start asking the question "shall we ship this"

pnkfelix (Apr 03 2020 at 14:43, on Zulip):

I don't think we can afford to schedule when the feature set will be filled in

nikomatsakis (Apr 03 2020 at 14:43, on Zulip):

I don't feel ready to set a scheduled time. I feel wary of over-extending ourselves right now.

bjorn3 (Apr 03 2020 at 14:43, on Zulip):

There are only two workers on which cg_clif works: x86_64 Linux and x86_64 MacOS

Jonas Schievink (Apr 03 2020 at 14:43, on Zulip):

If we gate on the backend building, every change to the compiler would cause ./x.py test to rebuild the entire backend, right? How long would that take?

centril (Apr 03 2020 at 14:43, on Zulip):

simulacrum said:

so I personally would rather not gate until we have parity etc

Fair point, but I'd also like to make sure that the LLVM backend doesn't increase the gap to parity, from my personal perspective on the lang team

bjorn3 (Apr 03 2020 at 14:44, on Zulip):

Jonas Schievink said:

If we gate on the backend building, every change to the compiler would cause ./x.py test to rebuild the entire backend, right? How long would that take?

If only cg_clif is rebuild and not it's dependencies for me ~40s in release mode with incr comp.

Wesley Wiser (Apr 03 2020 at 14:44, on Zulip):

If it were easy to run the tests with cranelift via x.py I probably would. On the other hand, it seems weird to gate the CI for something we don't ship at all. Looking at it from a platform support perspective, that would be like tier 3 which we don't run CI for.

nikomatsakis (Apr 03 2020 at 14:45, on Zulip):

Yes, I think that's a good way to look at it. I'd be happy moving it to something more like "tier 3"

nikomatsakis (Apr 03 2020 at 14:45, on Zulip):

Similarly, we don't run clippy tests

nikomatsakis (Apr 03 2020 at 14:45, on Zulip):

(Well, maybe we do? I forget, we do for some tools maybe?)

pnkfelix (Apr 03 2020 at 14:45, on Zulip):

it might be helpful to consider how we handled the transition to MIR

nikomatsakis (Apr 03 2020 at 14:45, on Zulip):

I was just thinking about that :) I couldn't remember very precisely

bjorn3 (Apr 03 2020 at 14:45, on Zulip):

-Zorbit

pnkfelix (Apr 03 2020 at 14:45, on Zulip):

we had the -Z orbit for that, right? @eddyb do you remember how we handled it?

centril (Apr 03 2020 at 14:46, on Zulip):

nikomatsakis said:

Similarly, we don't run clippy tests

We do, and we gate on it during the toolstate week

eddyb (Apr 03 2020 at 14:46, on Zulip):

I wish I could remember, hmpf

nikomatsakis (Apr 03 2020 at 14:46, on Zulip):

I think we kind of gradually phased it in --

pnkfelix (Apr 03 2020 at 14:46, on Zulip):

Its awesome that's we've all forgotten

eddyb (Apr 03 2020 at 14:46, on Zulip):

I think we had a ./configure flag that enabled it globally

nikomatsakis (Apr 03 2020 at 14:46, on Zulip):

it started out with specific tests, then we added orbit, then we started gating CI but not doing it by deafult, etc

pnkfelix (Apr 03 2020 at 14:46, on Zulip):

probably means it was an incredible success

eddyb (Apr 03 2020 at 14:46, on Zulip):

and I just fix every issue I could find

pnkfelix (Apr 03 2020 at 14:46, on Zulip):

vs NLL that everyone remembers because they hated compare-mode

eddyb (Apr 03 2020 at 14:46, on Zulip):

oh yeah didn't we add a separate CI builder?

eddyb (Apr 03 2020 at 14:46, on Zulip):

that went full -Zorbit

bjorn3 (Apr 03 2020 at 14:46, on Zulip):

cg_clif tests take about 9min on gh actions

eddyb (Apr 03 2020 at 14:47, on Zulip):

or maybe just for tests

centril (Apr 03 2020 at 14:47, on Zulip):

I think compare-mode is mostly a pain cause we don't do it on PR builders

nikomatsakis (Apr 03 2020 at 14:47, on Zulip):

centril said:

We do, and we gate on it during the toolstate week

(yeah, I withdraw the clippy comparison, but also that's a tool that we ship and support)

pnkfelix (Apr 03 2020 at 14:47, on Zulip):

Actually, now that I think about it

pnkfelix (Apr 03 2020 at 14:48, on Zulip):

the toolstate comparison may be apt

pnkfelix (Apr 03 2020 at 14:48, on Zulip):

have we talked about not gating bors merge on it, but still having CI run the tests?

pnkfelix (Apr 03 2020 at 14:48, on Zulip):

and then update the PR's with notice if they break it?

pnkfelix (Apr 03 2020 at 14:48, on Zulip):

analogous to toolstate?

centril (Apr 03 2020 at 14:48, on Zulip):

@pnkfelix that's a good compromise :+1:

pnkfelix (Apr 03 2020 at 14:48, on Zulip):

if we can afford it

pnkfelix (Apr 03 2020 at 14:49, on Zulip):

in terms of CI time

nikomatsakis (Apr 03 2020 at 14:49, on Zulip):

why don't we run compare-mode=nll on UI builders?

centril (Apr 03 2020 at 14:49, on Zulip):

GHA should make that possible

nikomatsakis (Apr 03 2020 at 14:49, on Zulip):

presumably CI time?

centril (Apr 03 2020 at 14:49, on Zulip):

@nikomatsakis yeah

nikomatsakis (Apr 03 2020 at 14:49, on Zulip):

so like...why would we do this?

nikomatsakis (Apr 03 2020 at 14:49, on Zulip):

it seems like we should do both :)

pnkfelix (Apr 03 2020 at 14:49, on Zulip):

My memory of the NLL thing

pnkfelix (Apr 03 2020 at 14:49, on Zulip):

was that we originally had it on by default for everyone

centril (Apr 03 2020 at 14:49, on Zulip):

@nikomatsakis well GHA will sorta change the CI calculus :P

pnkfelix (Apr 03 2020 at 14:49, on Zulip):

and developers, I remember @Vadim Petrochenkov in particular, raised concerns

centril (Apr 03 2020 at 14:50, on Zulip):

2 vcpus vs. 8 vcpus

pnkfelix (Apr 03 2020 at 14:50, on Zulip):

because it was adding local testing overhead

pnkfelix (Apr 03 2020 at 14:50, on Zulip):

Not CI overhead

pnkfelix (Apr 03 2020 at 14:50, on Zulip):

and so they pushed for us to turn it off by default

pnkfelix (Apr 03 2020 at 14:50, on Zulip):

I cannot remember anymore whether CI was a side-effect of that change

nikomatsakis (Apr 03 2020 at 14:50, on Zulip):

OK, well, we're 50 minutes in

pnkfelix (Apr 03 2020 at 14:50, on Zulip):

or a separate deliberate decision

centril (Apr 03 2020 at 14:50, on Zulip):

Should we summarize?

nikomatsakis (Apr 03 2020 at 14:51, on Zulip):

Maybe worth summarizing what we said, what we agreed upon, and what we didn't agree on yet

nikomatsakis (Apr 03 2020 at 14:51, on Zulip):
nikomatsakis (Apr 03 2020 at 14:51, on Zulip):
nikomatsakis (Apr 03 2020 at 14:52, on Zulip):

(and presumably some way to build/test the cranelift backend manually?)

nikomatsakis (Apr 03 2020 at 14:52, on Zulip):
nikomatsakis (Apr 03 2020 at 14:52, on Zulip):

concerns raised were about time, and also (I think) about the level of commitment implied, effect on contributors

centril (Apr 03 2020 at 14:53, on Zulip):

Proposals for gating on tests where:

nikomatsakis (Apr 03 2020 at 14:53, on Zulip):

balanced against the benefits of keeping tests up to date

nikomatsakis (Apr 03 2020 at 14:53, on Zulip):

actually I don't think anyone talked about "blocking on it during the last week"

nikomatsakis (Apr 03 2020 at 14:53, on Zulip):

at least I don't think @pnkfelix meant to imply that

simulacrum (Apr 03 2020 at 14:53, on Zulip):

(Certainly doesn't make sense for last week -- it'd be similar I think to how we gate miri toolstate -- i.e. never)

pnkfelix (Apr 03 2020 at 14:54, on Zulip):

nikomatsakis said:

at least I don't think pnkfelix meant to imply that

I definitely didn't want to imply that

centril (Apr 03 2020 at 14:54, on Zulip):

Ah so there's a fourth proposal

Wesley Wiser (Apr 03 2020 at 14:54, on Zulip):

If we're not shipping a rustup component, I don't know why we'd block during the last week.

nikomatsakis (Apr 03 2020 at 14:54, on Zulip):

that's my sense as well, if it's not something we're going to ship in stable, who cares what week it is?

pnkfelix (Apr 03 2020 at 14:54, on Zulip):

not until we ship this

centril (Apr 03 2020 at 14:54, on Zulip):

(added the 4th proposal)

nikomatsakis (Apr 03 2020 at 14:55, on Zulip):

OK, great.

nikomatsakis (Apr 03 2020 at 14:55, on Zulip):
centril (Apr 03 2020 at 14:55, on Zulip):

So how do folks feel about?:

nikomatsakis (Apr 03 2020 at 14:55, on Zulip):

I want to think about it

nikomatsakis (Apr 03 2020 at 14:55, on Zulip):

I would be happy to make some decisions about that after we've taken a few other steps, too, so we have some more experience

simulacrum (Apr 03 2020 at 14:56, on Zulip):

(Personally I think we should get all the infrastructure in place before figuring out to what extent to gate)

nikomatsakis (Apr 03 2020 at 14:57, on Zulip):

OK, thanks everyone, productive meeting. One final question:

Is there someone who would be willing to go through and make a PR with minutes from this meeting?

Wesley Wiser (Apr 03 2020 at 14:57, on Zulip):

I will

centril (Apr 03 2020 at 14:57, on Zulip):

nikomatsakis said:

Folks can notify @bjorn3 of their interest?

nikomatsakis (Apr 03 2020 at 14:58, on Zulip):

(Also, @bjorn3, I think that an appropriate next step would be to make a "major change proposal" with the "consensus changes" described above described in a bit more detail.)

nikomatsakis (Apr 03 2020 at 14:58, on Zulip):

Thanks @Wesley Wiser re: minutes, and thanks to everyone else for attending!

bjorn3 (Apr 04 2020 at 14:59, on Zulip):

nikomatsakis said:

(Also, bjorn3, I think that an appropriate next step would be to make a "major change proposal" with the "consensus changes" described above described in a bit more detail.)

compiler-team#270

Last update: May 29 2020 at 16:45UTC