Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom MIR: Many more improvements #105356

Merged
merged 5 commits into from
Dec 15, 2022
Merged

Conversation

JakobDegen
Copy link
Contributor

@JakobDegen JakobDegen commented Dec 6, 2022

Commits are each atomic changes, best reviewed one at a time, with the exception that the last commit includes all the documentation.

First commit

Unsafetyck was not correctly disabled before for dialect = "built" custom MIR. This is fixed and a regression test is added.

Second commit

Implements Discriminant, SetDiscriminant, and SwitchInt.

Third commit

Implements indexing, field, and variant projections.

Fourth commit

Documents the previous commits and everything else.

There is some amount of weirdness here due to having to beat Rust syntax into cooperating with MIR concepts, but it hopefully should not be too much. All of it is documented.

r? @oli-obk

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 6, 2022
@rustbot
Copy link
Collaborator

rustbot commented Dec 6, 2022

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

@JakobDegen
Copy link
Contributor Author

Oh, did not mean to reping everyone. Sorry about that

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@oli-obk
Copy link
Contributor

oli-obk commented Dec 6, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Dec 6, 2022

📌 Commit c3d532e8f2b3036f6b09cc5cab653c952d90822f has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 6, 2022
@JakobDegen
Copy link
Contributor Author

@oli-obk probably shouldn't merge this until the parent is merged

@oli-obk
Copy link
Contributor

oli-obk commented Dec 6, 2022

@bors r- oh right, there was a reason I didn't r+ this earlier ^^ I thought it was jsut CI

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 6, 2022
@bors
Copy link
Contributor

bors commented Dec 8, 2022

☔ The latest upstream changes (presumably #105425) made this pull request unmergeable. Please resolve the merge conflicts.

//! extern crate core;
//! use core::intrinsics::mir::*;
//!
//! #[custom_mir(dialect = "built")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a dialect? Perhaps I'm just supposed to know this, but it's not documented anywhere here and somehow I've escaped learning about this concept.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs. I've added a link and brief explanation

//! #### Rvalues
//!
//! - Operands implicitly convert to `Use` rvalues.
//! - `&`, `&mut`, `addr_of!`, and `addr_of_mut!` all work to create their associated rvalue.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why addr_of! instead of &raw? IMO this is going too far in trying to imitate the way people write surface Rust, and &raw makes more sense here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&raw works just as well. `addr_of! literally just expands to that, the only difference is that you don't need to turn on a feature to use the latter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. addr_of! just seems like a very high-level construct to adopt as custom MIR syntax. And personally I like the symmetry of &, &raw, &mut.

//! #### Terminators
//!
//! - [`Goto`] and [`Return`] have associated functions.
//! - `match some_int_operand` becomes a `SwitchInt`. Each arm should be `literal => basic_block`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The choice to use Rust match syntax makes RET and Return() even more odd. I think in this case it might just be better to at least call it SwitchInt, because otherwise it seems to easy to forget that this match only works on integers.

@saethlin
Copy link
Member

Jake asked me for comments in general, and I have some comments that are not on lines changed in this PR:

        exit = {
            temp2 = Move(temp1);
            RET = temp2;
            Return()
        }

At this stage, reading this in the docs, it's entirely unclear to me whether exit is a magic block name. Perhaps pick a different name.

RET as a magic name for the return place is odd. We only use shouty case for consts and statics in Rust, and I don't think it is used anywhere in MIR. I don't have a suggestion for a better name. It's probably a step up from just having to know that _0 is very different from _1 but I hope we can do better?

Return() is an odd choice amongst all this other syntax; declaration and assignment exactly mirrors Rust, why not the syntax for returning from a function?

@JakobDegen
Copy link
Contributor Author

RET as a magic name for the return place is odd. We only use shouty case for consts and statics in Rust, and I don't think it is used anywhere in MIR. I don't have a suggestion for a better name.

I don't have a better idea either. I suppose ret in lower case is an option? The uppercase might help let people know that they should not be looking for an associated let-statement.

I think in this case it might just be better to at least call it SwitchInt

declaration and assignment exactly mirrors Rust, why not the syntax for returning from a function?

The mir! macro has to expand to something that parses and type checks normally. That means any new syntax we introduce has to be re-written by the macro (keeping in mind that this is a macro_rules!). I could do that for switch_int foo { ... } => match foo { ... }, but that might not be easier to remember, and it's likely to degrade error messages as spans get mangled.

return syntax has the same problem. I'd have to re-write it to Return() in the macro (since return; won't type check in a function returning i32). The problem is that I then don't have anything great to do with return 5;. I can try and detect that in the macro too, but the compiler_error! I generate won't have a good span. I'm not so sure that's better

@saethlin
Copy link
Member

Thanks for the improvements 👍

The limitations of the syntax make a bit more sense knowing a bit about the implementation 😉 though I wonder about the wisdom of using macro_rules! for something so complicated, I understand the tradeoff you're juggling and I'm not sure I would do it differently.

@JakobDegen
Copy link
Contributor Author

though I wonder about the wisdom of using macro_rules! for something so complicated

I would love to write a proc macro for this instead, but then it wouldn't be available in std and that seems like it defeats most of the point

@oli-obk
Copy link
Contributor

oli-obk commented Dec 14, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Dec 14, 2022

📌 Commit b580f29 has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 14, 2022
@bors
Copy link
Contributor

bors commented Dec 15, 2022

⌛ Testing commit b580f29 with merge ec56537...

@bors
Copy link
Contributor

bors commented Dec 15, 2022

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing ec56537 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 15, 2022
@bors bors merged commit ec56537 into rust-lang:master Dec 15, 2022
@rustbot rustbot added this to the 1.68.0 milestone Dec 15, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (ec56537): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.6% [0.6%, 0.6%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.2% [2.2%, 2.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-2.3% [-2.4%, -2.2%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.8% [-2.4%, 2.2%] 3

Cycles

This benchmark run did not return any relevant results for this metric.

@JakobDegen JakobDegen deleted the more-custom-mir branch December 16, 2022 13:44
Aaron1011 pushed a commit to Aaron1011/rust that referenced this pull request Jan 6, 2023
Custom MIR: Many more improvements

Commits are each atomic changes, best reviewed one at a time, with the exception that the last commit includes all the documentation.

### First commit

Unsafetyck was not correctly disabled before for `dialect = "built"` custom MIR. This is fixed and a regression test is added.

### Second commit

Implements `Discriminant`, `SetDiscriminant`, and `SwitchInt`.

### Third commit

Implements indexing, field, and variant projections.

### Fourth commit

Documents the previous commits and everything else.

There is some amount of weirdness here due to having to beat Rust syntax into cooperating with MIR concepts, but it hopefully should not be too much. All of it is documented.

r? `@oli-obk`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants