Stream: t-compiler

Topic: MIR librarification compiler-team#233


nikomatsakis (Dec 23 2019 at 13:23, on Zulip):

@oli with respect to compiler-team#233 -- I have a few questions:

In particular, I think it would be nice if we could have a library that

that was independently testable and embeddable from rustc.

In my ideal world, it might also cover lowering to LLVM IR, but I'm not sure if that's possible.

oli (Dec 23 2019 at 13:23, on Zulip):

I want to move the entire MIR. So a generic form of mir::Body

oli (Dec 23 2019 at 13:24, on Zulip):

And yes, my original motivation was writing optimizations without tieing them to rustc

oli (Dec 23 2019 at 13:25, on Zulip):

well... codegen is already pretty nicely abstracted. I'm sure we can come up with someting

oli (Dec 23 2019 at 13:26, on Zulip):

Potentially we can even make mir interpretation generic enough so that we can start using it without rustc

centril (Dec 23 2019 at 13:34, on Zulip):

hmm, but it's not like you can switch out Ty for some other notion of types that is semantically different... so it would just be another representation for the same thing?

centril (Dec 23 2019 at 13:38, on Zulip):

If we implement logic over this generic MIR then you give up the ability to pattern match on types in that logic

oli (Dec 23 2019 at 13:39, on Zulip):

maybe, this needs to be explored, but my hope is that we can come up with something

oli (Dec 23 2019 at 13:39, on Zulip):

chalk-ir has some helper traits around types

centril (Dec 23 2019 at 13:43, on Zulip):

Well, you'd need associated pattern aliases with exhaustiveness groupings to be able to use match again

centril (Dec 23 2019 at 13:43, on Zulip):

otherwise you'll need to use .is_foobar() and .as_foobar() and largely give up exhaustive matches

centril (Dec 23 2019 at 13:44, on Zulip):

(which feels like it would make a part of the compiler, that needs to be especially robust, more brittle)

oli (Dec 23 2019 at 13:44, on Zulip):

I don't think we exhaustively match Ty a lot

oli (Dec 23 2019 at 13:45, on Zulip):

There are many many things we can move without making stuff less robust in anyone's metric

oli (Dec 23 2019 at 13:46, on Zulip):

I feel like we should have this discussion once we have concrete things that are weird to move

oli (Dec 23 2019 at 13:47, on Zulip):

just making things more generic is not a goal in itself, so when we hit something that requires weird trait bounds with weird APIs then we should definitely be careful

nikomatsakis (Dec 23 2019 at 16:46, on Zulip):

hmm, but it's not like you can switch out Ty for some other notion of types that is semantically different... so it would just be another representation for the same thing?

I was expecting to parameterize it eventually in the style of chalk-ir, which means that yes it's really mostly about the representation. chalk-ir in particular does permit matching (because the generic notion can convert itself to a TyData)

nikomatsakis (Dec 23 2019 at 16:48, on Zulip):

However, I'm not sure if that's the best approach -- I guess it would be worth looking at how much different optimizations and things that operate over MIR care about Rust types (and which aspects they care about)

centril (Dec 23 2019 at 17:59, on Zulip):

chalk-ir in particular does permit matching (because the generic notion can convert itself to a TyData)

So it's sort of tag-less final + a conversion to an initial repr... sounds possibly expensive though :slight_smile:

Zoxc (Dec 29 2019 at 19:00, on Zulip):

You also have to deal with accessing TyCtxt which also adds some complexity.

I'd like a rustc_mir_types crate (basically just rustc::mir) and have rustc_mir depend on it. Though that is mostly for compile time reasons. rustc_mir should be split up too, but that shouldn't be too hard. We could start with that and let rustc_mirstill use rustc and the concrete Ty type.

Zoxc (Dec 29 2019 at 19:26, on Zulip):

We can have matching by defining a generic enum TyKind<T> where T is the concrete Ty<'tcx>. That should have no performance impact.

Zoxc (Dec 29 2019 at 19:29, on Zulip):

Having an specific TyKind for Mir which doesn't expose variants which can't occur in Mir could be handy.

Last update: May 26 2020 at 10:45UTC