Stream: t-compiler/wg-mir-opt

Topic: Standalone mir-opt tool


Luqman Aden (Jul 14 2020 at 19:16, on Zulip):

Curious if there were any eventual plans for a standalone mir-opt tool (akin to Swift's sil-opt or LLVM's opt) to take in MIR and output the result after optimizations. Would definitely help while writing/testing mir opts without having to rely on rustc generating the right mir you want to test.

bjorn3 (Jul 14 2020 at 19:22, on Zulip):

https://github.com/rust-lang/miri/issues/196

bjorn3 (Jul 14 2020 at 19:24, on Zulip):

It is not as easy as for LLVM or Swift, as MIR itself just describes function bodies. It doesn't describe any types and other necessary things to actually do something useful with it.

bjorn3 (Jul 14 2020 at 19:25, on Zulip):

LLVM-IR at least describes the full input of the optimizations. Rust's MIR doesn't.

Luqman Aden (Jul 14 2020 at 19:26, on Zulip):

bjorn3 said:

https://github.com/rust-lang/miri/issues/196

Ah, there's the issue I could've sworn I saw a while back :smile:

Luqman Aden (Jul 14 2020 at 19:28, on Zulip):

bjorn3 said:

It is not as easy as for LLVM or Swift, as MIR itself just describes function bodies. It doesn't describe any types and other necessary things to actually do something useful with it.

yea, i guess it'd need some sort of augmented mir

eddyb (Jul 14 2020 at 22:14, on Zulip):

you would need something like Rust but with macros expanded, and function bodies replaced with MIR

eddyb (Jul 14 2020 at 22:15, on Zulip):

in fact we could try to make something like this work for testing

Félix Fischer (Jul 14 2020 at 22:29, on Zulip):

^ ditto

Félix Fischer (Jul 14 2020 at 22:29, on Zulip):

I would love to see this available for testing MIR

Félix Fischer (Jul 14 2020 at 22:30, on Zulip):

I mean not MIR, but transformations over MIR

RalfJ (Jul 15 2020 at 07:34, on Zulip):

it would also tremendously help exploring MIR semantics with miri

RalfJ (Jul 15 2020 at 07:34, on Zulip):

right now there's MIR we just cannot generate so we cannot actually test how miri behaves on them and whether that's what we want

oli (Jul 15 2020 at 08:12, on Zulip):

Maybe we could add an forever unstable mir item kind to the parser, ast, hir and translate that directly to MIR bodies?

eddyb (Jul 15 2020 at 08:16, on Zulip):

@oli I would just have a way to toggle what the body is supposed to be

eddyb (Jul 15 2020 at 08:16, on Zulip):

ideally we can avoid parsing anything special and just have a transformation to lower AST to MIR

eddyb (Jul 15 2020 at 08:16, on Zulip):

that AST -> HIR would invoke

eddyb (Jul 15 2020 at 08:17, on Zulip):

creating types is a bit of a problem, since TyCtxt doesn't exist yet, hmpf

eddyb (Jul 15 2020 at 08:18, on Zulip):

maybe we can just do AST -> HIR and avoid using anything that woul desugar

eddyb (Jul 15 2020 at 08:18, on Zulip):

@oli so basically it would look like a bunch of function calls

eddyb (Jul 15 2020 at 08:18, on Zulip):

mostly,

eddyb (Jul 15 2020 at 08:18, on Zulip):

I forogt where I wrote down my last thoughts on this

oli (Jul 15 2020 at 08:19, on Zulip):

right, but I want to write normal code and mir in the same file ^^

eddyb (Jul 15 2020 at 08:19, on Zulip):

but yeah parsing -> AST -> HIR without any changes to the AST or HIR would be great because you can defer reinterpeting it as MIR until after you have a TyCtxt

oli (Jul 15 2020 at 08:19, on Zulip):

and we'll want to write basic blocks with arbitrary schemes, so we can't just use rust code

eddyb (Jul 15 2020 at 08:19, on Zulip):

@oli that's the point, you have like a #[mir] or something annotation

oli (Jul 15 2020 at 08:19, on Zulip):

even loop is not ok?

eddyb (Jul 15 2020 at 08:19, on Zulip):

you'd be using a subset of the Rust syntax as a way to represent MIR

eddyb (Jul 15 2020 at 08:20, on Zulip):

to avoid wriitng a MIR parser etc.

eddyb (Jul 15 2020 at 08:20, on Zulip):

if you want to do all that extra work, be my guest, but I don't think it's entirely worth it

oli (Jul 15 2020 at 08:20, on Zulip):

oh, so you want SetDiscriminant(place, val) to be a function?

eddyb (Jul 15 2020 at 08:21, on Zulip):

not a real one, just using the syntax

oli (Jul 15 2020 at 08:21, on Zulip):

yea

oli (Jul 15 2020 at 08:21, on Zulip):

basically an intrinsic ^^

eddyb (Jul 15 2020 at 08:21, on Zulip):

hopefully the syntax we pick will be weird enough so that it wouldn't actually compile without the #[mir] or w/e...

oli (Jul 15 2020 at 08:23, on Zulip):

as a first step we can create a bunch of intrinsics that cover all the mir statement kinds and only work with -Zunstable-features

oli (Jul 15 2020 at 08:24, on Zulip):

that seems like the MVP which is the easiest to implement and gives us fun things like inserting StorageDead in random places

eddyb (Jul 15 2020 at 08:28, on Zulip):

you went in the direction I really wanted to avoid, but I suppose it wouldn't be impossible to have that available for testing

eddyb (Jul 15 2020 at 08:29, on Zulip):

I'm worried about putting anything mentioning those intrinsics in core/std, maybe we need to start having a rustc_test crate with random goodies tests can easily access?

eddyb (Jul 15 2020 at 08:31, on Zulip):

anyway that feels orthogonal to being able to inject custom MIR bodies (which would likely require a special "HIR->MIR direct lowering" pass that bypasses typeck and regular MIR building)

oli (Jul 15 2020 at 08:31, on Zulip):

we don't need to put these intrinsics in core/std

oli (Jul 15 2020 at 08:31, on Zulip):

we can just add a new crate for mir debugging

eddyb (Jul 15 2020 at 08:32, on Zulip):

rustc_test or rustc_mir_test if we don't want to use one crate for everything, seems like it could work fine

Last update: Sep 28 2020 at 16:00UTC