mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7cf7ead0bc
rust/src/test/mir-opt/early_otherwise_branch.opt2.EarlyOtherwiseBranch.diff

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

93 lines
6.4 KiB
Diff
Raw Normal View History

New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
- // MIR for `opt2` before EarlyOtherwiseBranch
+ // MIR for `opt2` after EarlyOtherwiseBranch
bless
2020-09-19 16:50:51 -05:00
fn opt2(_1: Option<u32>, _2: Option<u32>) -> u32 {
debug x => _1; // in scope 0 at $DIR/early_otherwise_branch.rs:11:9: 11:10
debug y => _2; // in scope 0 at $DIR/early_otherwise_branch.rs:11:25: 11:26
let mut _0: u32; // return place in scope 0 at $DIR/early_otherwise_branch.rs:11:44: 11:47
let mut _3: (std::option::Option<u32>, std::option::Option<u32>); // in scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
let mut _4: std::option::Option<u32>; // in scope 0 at $DIR/early_otherwise_branch.rs:12:12: 12:13
let mut _5: std::option::Option<u32>; // in scope 0 at $DIR/early_otherwise_branch.rs:12:15: 12:16
let mut _6: isize; // in scope 0 at $DIR/early_otherwise_branch.rs:14:16: 14:20
let mut _7: isize; // in scope 0 at $DIR/early_otherwise_branch.rs:13:19: 13:26
let mut _8: isize; // in scope 0 at $DIR/early_otherwise_branch.rs:13:10: 13:17
let _9: u32; // in scope 0 at $DIR/early_otherwise_branch.rs:13:15: 13:16
let _10: u32; // in scope 0 at $DIR/early_otherwise_branch.rs:13:24: 13:25
Correct the unsoundness in the `EarlyOtherwiseBranch` mir opt This optimization pass previously made excessive assumptions as to the nature of the blocks being optimized. We remove those assumptions and make sure to rigorously justify all changes that are made to the MIR. Details can be found in the file.
2021-12-12 15:53:15 -06:00
+ let mut _11: isize; // in scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
+ let mut _12: bool; // in scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
scope 1 {
bless
2020-09-19 16:50:51 -05:00
debug a => _9; // in scope 1 at $DIR/early_otherwise_branch.rs:13:15: 13:16
debug b => _10; // in scope 1 at $DIR/early_otherwise_branch.rs:13:24: 13:25
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
bb0: {
bless
2020-09-19 16:50:51 -05:00
StorageLive(_3); // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
StorageLive(_4); // scope 0 at $DIR/early_otherwise_branch.rs:12:12: 12:13
_4 = _1; // scope 0 at $DIR/early_otherwise_branch.rs:12:12: 12:13
StorageLive(_5); // scope 0 at $DIR/early_otherwise_branch.rs:12:15: 12:16
_5 = _2; // scope 0 at $DIR/early_otherwise_branch.rs:12:15: 12:16
Fix tests broken by deaggregation change
2022-04-05 18:02:57 -05:00
Deinit(_3); // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
bless
2020-09-19 16:50:51 -05:00
(_3.0: std::option::Option<u32>) = move _4; // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
(_3.1: std::option::Option<u32>) = move _5; // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
StorageDead(_5); // scope 0 at $DIR/early_otherwise_branch.rs:12:16: 12:17
StorageDead(_4); // scope 0 at $DIR/early_otherwise_branch.rs:12:16: 12:17
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
_8 = discriminant((_3.0: std::option::Option<u32>)); // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
Switch some tests over to new MIR opt unit tests
2022-04-13 04:20:46 -05:00
- switchInt(move _8) -> [0_isize: bb1, 1_isize: bb3, otherwise: bb2]; // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
+ StorageLive(_11); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
+ _11 = discriminant((_3.1: std::option::Option<u32>)); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
+ StorageLive(_12); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
Correct the unsoundness in the `EarlyOtherwiseBranch` mir opt This optimization pass previously made excessive assumptions as to the nature of the blocks being optimized. We remove those assumptions and make sure to rigorously justify all changes that are made to the MIR. Details can be found in the file.
2021-12-12 15:53:15 -06:00
+ _12 = Ne(_8, move _11); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
+ StorageDead(_11); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
+ switchInt(move _12) -> [false: bb5, otherwise: bb1]; // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
bb1: {
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
- _6 = discriminant((_3.1: std::option::Option<u32>)); // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
- switchInt(move _6) -> [0_isize: bb5, otherwise: bb2]; // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
add cleanup of cfg
2020-09-19 18:18:05 -05:00
- }
-
- bb2: {
insert storageDead for not equal temp
2020-09-19 18:09:18 -05:00
+ StorageDead(_12); // scope 0 at $DIR/early_otherwise_branch.rs:15:14: 15:15
bless
2020-09-19 16:50:51 -05:00
_0 = const 1_u32; // scope 0 at $DIR/early_otherwise_branch.rs:15:14: 15:15
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
- goto -> bb6; // scope 0 at $DIR/early_otherwise_branch.rs:15:14: 15:15
+ goto -> bb4; // scope 0 at $DIR/early_otherwise_branch.rs:15:14: 15:15
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
add cleanup of cfg
2020-09-19 18:18:05 -05:00
- bb3: {
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
- _7 = discriminant((_3.1: std::option::Option<u32>)); // scope 0 at $DIR/early_otherwise_branch.rs:12:11: 12:17
- switchInt(move _7) -> [1_isize: bb4, otherwise: bb2]; // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
add cleanup of cfg
2020-09-19 18:18:05 -05:00
- }
-
- bb4: {
+ bb2: {
bless
2020-09-19 16:50:51 -05:00
StorageLive(_9); // scope 0 at $DIR/early_otherwise_branch.rs:13:15: 13:16
_9 = (((_3.0: std::option::Option<u32>) as Some).0: u32); // scope 0 at $DIR/early_otherwise_branch.rs:13:15: 13:16
StorageLive(_10); // scope 0 at $DIR/early_otherwise_branch.rs:13:24: 13:25
_10 = (((_3.1: std::option::Option<u32>) as Some).0: u32); // scope 0 at $DIR/early_otherwise_branch.rs:13:24: 13:25
_0 = const 0_u32; // scope 1 at $DIR/early_otherwise_branch.rs:13:31: 13:32
StorageDead(_10); // scope 0 at $DIR/early_otherwise_branch.rs:13:31: 13:32
StorageDead(_9); // scope 0 at $DIR/early_otherwise_branch.rs:13:31: 13:32
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
- goto -> bb6; // scope 0 at $DIR/early_otherwise_branch.rs:13:31: 13:32
+ goto -> bb4; // scope 0 at $DIR/early_otherwise_branch.rs:13:31: 13:32
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
add cleanup of cfg
2020-09-19 18:18:05 -05:00
- bb5: {
+ bb3: {
bless
2020-09-19 16:50:51 -05:00
_0 = const 0_u32; // scope 0 at $DIR/early_otherwise_branch.rs:14:25: 14:26
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
- goto -> bb6; // scope 0 at $DIR/early_otherwise_branch.rs:14:25: 14:26
+ goto -> bb4; // scope 0 at $DIR/early_otherwise_branch.rs:14:25: 14:26
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
add cleanup of cfg
2020-09-19 18:18:05 -05:00
- bb6: {
+ bb4: {
bless
2020-09-19 16:50:51 -05:00
StorageDead(_3); // scope 0 at $DIR/early_otherwise_branch.rs:17:1: 17:2
return; // scope 0 at $DIR/early_otherwise_branch.rs:17:2: 17:2
exp-stuff-dirty
2022-04-27 17:03:07 -05:00
+ }
+
add cleanup of cfg
2020-09-19 18:18:05 -05:00
+ bb5: {
Correct the unsoundness in the `EarlyOtherwiseBranch` mir opt This optimization pass previously made excessive assumptions as to the nature of the blocks being optimized. We remove those assumptions and make sure to rigorously justify all changes that are made to the MIR. Details can be found in the file.
2021-12-12 15:53:15 -06:00
+ StorageDead(_12); // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
+ switchInt(_8) -> [0_isize: bb3, 1_isize: bb2, otherwise: bb1]; // scope 0 at $DIR/early_otherwise_branch.rs:12:5: 12:17
New MIR optimization pass to reduce branches on match of tuples of enums
2020-08-01 18:47:52 -05:00
}
}
Reference in New Issue Copy Permalink