cfallin commented on issue #7465:
Last merge-queue test run seemed to show a real assert failure during compilation:
thread '<unnamed>' panicked at 'assertion failed: x < (1 << bits)', cranelift/codegen/src/ir/dfg.rs:557:9
weird that it only reproduces on the MSRV run and for an integration test?
alexcrichton commented on issue #7465:
I'm going to remove from the queue due to ^
fitzgen commented on issue #7465:
It looks like we are creating a union of two values and the values' indices don't fit in the packed representation
fitzgen commented on issue #7465:
Does anyone know how to run the tokio example, or at least build the wasms that it uses?
cargo build --target wasm32-wasi
insideexamples/tokio/wasm
doesn't seem to actually produce any wasm files for me.
alexcrichton commented on issue #7465:
cargo build --target wasm32-wasi --manifest-path examples/tokio/wasm/Cargo.toml cargo run --example tokio --features wasmtime-wasi/tokio
fitzgen commented on issue #7465:
Hm I can't reproduce the assertion failure for that example.
But I did find an off-by-one bug in the assertion. It allows
0x00ff_ffff
to be encoded as-is but that conflicts with the sentinal we use to represent0xffff_ffff
. Tweaked to fix the assertion.
fitzgen edited a comment on issue #7465:
Hm I can't reproduce the assertion failure for that example.
But I did find an off-by-one bug in the assertion. It allows
0x0000_0fff
to be encoded as-is but that conflicts with the sentinal we use to represent0xffff_ffff
. Tweaked to fix the assertion.
fitzgen commented on issue #7465:
Okay I was able to repro with the 1.71.0 toolchain. Interestingly enough, it seemed to hang for a while before actually panicking, when the other toolchains ran to completion almost immediately.
fitzgen commented on issue #7465:
Still going (it is generating a lot of output) but it looks like we've gone into some kind of loop where we are unioning values like
x, x+1, x+2, ...
. Since this only shows up on 1.71.0, I'm thinking this might be a miscompile in rustc/llvm?FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db0, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db1, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db2, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db3, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db4, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db5, y = 0xc29d09) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db6, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db7, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db8, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90db9, y = 0xc29d09) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dba, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dbb, y = 0xc29d1f) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dbc, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dbd, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dbe, y = 0xc29d09) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dbf, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dc0, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dc1, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dc2, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xe90dc3, y = 0xc29d09)
fitzgen commented on issue #7465:
Yep, it just finished:
FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffff9, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffffa, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffffb, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffffc, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffffd, y = 0xc29cf9) FITZGEN: packing union(tag = 11, ty = 79, x = 0xfffffe, y = 0xc29d09) FITZGEN: packing union(tag = 11, ty = 79, x = 0xffffff, y = 0xc29cf9) thread '<unnamed>' panicked at '16777215 does not fit into 24 bits (must be less than 16777215 to allow for a 0xffffffff sentinal)', cranelift/codegen/src/ir/dfg.rs:558:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fitzgen edited a comment on issue #7465:
Hm I can't reproduce the assertion failure for that example.
But I did find an off-by-one bug in the assertion. It allows
0x00ff_ffff
to be encoded as-is but that conflicts with the sentinal we use to represent0xffff_ffff
. Tweaked to fix the assertion.
github-actions[bot] commented on issue #7465:
Subscribe to Label Action
cc @cfallin, @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
- cfallin: isle
- fitzgen: isle
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
fitzgen commented on issue #7465:
I can't reproduce the test failure in CI. I'm also on linux x64 and using rust 1.73. Not sure what is up here.
afonso360 commented on issue #7465:
Hey, I ran the fuzzer on RISC-V overnight on this branch, to check if there is something wrong with the RISC-V backend. I don't know if there is yet, but I think I got a reproduction of the issue that was happening in CI earlier.
<details>
<summary>Testcase</summary>;; Run test case test interpret test run set opt_level=speed_and_size target riscv64gc has_zca has_zcd function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { ss0 = explicit_slot 29 ss1 = explicit_slot 17 ss2 = explicit_slot 49 ss3 = explicit_slot 52 ss4 = explicit_slot 17 ss5 = explicit_slot 17 block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v54 -> v1 v37 = rotl v0, v10 v38 = rotl v37, v10 v39 = rotl v38, v10 v40 = rotl v39, v10 v41 = rotl v40, v10 v42 = rotl v41, v10 v43 = select_spectre_guard v1, v10, v10 v44 = bxor_not v43, v43 v55 -> v44 v45 = bitrev v42 v46 = sextend.i128 v45 v47 = rotl v45, v44 v48 = rotl v47, v44 v49 = select v48, v48, v48 v50 = rotl v49, v44 v51 = rotl v50, v44 v52 = rotl v51, v44 v53 = rotl v52, v44 v58 -> v53 v56 = select_spectre_guard.i32 v54, v55, v55 v57 = bxor_not v56, v56 v59 = bitrev.i8 v58 v61 = rotl v59, v57 v62 = rotl v61, v57 v63 = select v62, v62, v62 v64 = rotl v63, v57 v65 = rotl v64, v57 v66 = rotl v65, v57 v67 = rotl v66, v57 v68 = rotr v67, v54 v69 = rotl v68, v57 v70 = rotl v69, v57 v71 = rotl v70, v57 v72 = rotl v71, v57 v73 = rotl v72, v57 return v73 } ; run: %a(17, 4474, 4803839602528529, -10005959247738946646150328352768, 19070975, 281564249487374563584566874706289408, 8440, 0, 0, 0, 0, 0.0, 0) == 34
</details>
<details>
<summary>Egraphs Resultmain
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v91 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v91, v91 ; v91 = 0xffff_ffff, v91 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v82 = iadd v79, v10 v85 = iadd v82, v10 v88 = iadd v85, v10 v89 = rotl v0, v88 v45 = bitrev v89 v215 = iconst.i32 2 v217 = rotl v45, v215 ; v215 = 2 v59 = bitrev v217 v308 = uextend.i32 v1 v310 = isub v308, v215 ; v215 = 2 v311 = ineg v310 v404 = iconst.i32 0xffff_fffb v406 = iadd v311, v404 ; v404 = 0xffff_fffb v408 = rotl v59, v406 return v408 }
</details>
<details>
<summary>Egraphs Resultfix-egraph-union
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v251 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v251, v251 ; v251 = 0xffff_ffff, v251 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v93 = iadd v79, v10 v130 = iadd v10, v93 v176 = iadd v10, v130 v177 = rotl v0, v176 v45 = bitrev v177 v679 = iconst.i32 10 v681 = rotl v45, v679 ; v679 = 10 v59 = bitrev v681 v376 = iconst.i32 0xffff_fffd v1116 = uextend.i32 v1 v1161 = isub v376, v1116 ; v376 = 0xffff_fffd v1936 = rotl v59, v1161 return v1936 }
</details>
This testcase spends a huge amount of time in egraphs with this PR and it now fails where it didn't before. Although I'm not 100% sure this isn't a bug in one of the rules that wasn't discovered previously.
I'm going to look into this again later today
afonso360 edited a comment on issue #7465:
Hey, I ran the fuzzer on RISC-V overnight on this branch to check if there is something wrong with the RISC-V backend. I don't know if there is yet, but I think I got a reproduction of the issue that was happening in CI earlier.
<details>
<summary>Testcase</summary>;; Run test case test interpret test run set opt_level=speed_and_size target riscv64gc has_zca has_zcd function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { ss0 = explicit_slot 29 ss1 = explicit_slot 17 ss2 = explicit_slot 49 ss3 = explicit_slot 52 ss4 = explicit_slot 17 ss5 = explicit_slot 17 block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v54 -> v1 v37 = rotl v0, v10 v38 = rotl v37, v10 v39 = rotl v38, v10 v40 = rotl v39, v10 v41 = rotl v40, v10 v42 = rotl v41, v10 v43 = select_spectre_guard v1, v10, v10 v44 = bxor_not v43, v43 v55 -> v44 v45 = bitrev v42 v46 = sextend.i128 v45 v47 = rotl v45, v44 v48 = rotl v47, v44 v49 = select v48, v48, v48 v50 = rotl v49, v44 v51 = rotl v50, v44 v52 = rotl v51, v44 v53 = rotl v52, v44 v58 -> v53 v56 = select_spectre_guard.i32 v54, v55, v55 v57 = bxor_not v56, v56 v59 = bitrev.i8 v58 v61 = rotl v59, v57 v62 = rotl v61, v57 v63 = select v62, v62, v62 v64 = rotl v63, v57 v65 = rotl v64, v57 v66 = rotl v65, v57 v67 = rotl v66, v57 v68 = rotr v67, v54 v69 = rotl v68, v57 v70 = rotl v69, v57 v71 = rotl v70, v57 v72 = rotl v71, v57 v73 = rotl v72, v57 return v73 } ; run: %a(17, 4474, 4803839602528529, -10005959247738946646150328352768, 19070975, 281564249487374563584566874706289408, 8440, 0, 0, 0, 0, 0.0, 0) == 34
</details>
<details>
<summary>Egraphs Resultmain
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v91 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v91, v91 ; v91 = 0xffff_ffff, v91 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v82 = iadd v79, v10 v85 = iadd v82, v10 v88 = iadd v85, v10 v89 = rotl v0, v88 v45 = bitrev v89 v215 = iconst.i32 2 v217 = rotl v45, v215 ; v215 = 2 v59 = bitrev v217 v308 = uextend.i32 v1 v310 = isub v308, v215 ; v215 = 2 v311 = ineg v310 v404 = iconst.i32 0xffff_fffb v406 = iadd v311, v404 ; v404 = 0xffff_fffb v408 = rotl v59, v406 return v408 }
</details>
<details>
<summary>Egraphs Resultfix-egraph-union
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v251 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v251, v251 ; v251 = 0xffff_ffff, v251 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v93 = iadd v79, v10 v130 = iadd v10, v93 v176 = iadd v10, v130 v177 = rotl v0, v176 v45 = bitrev v177 v679 = iconst.i32 10 v681 = rotl v45, v679 ; v679 = 10 v59 = bitrev v681 v376 = iconst.i32 0xffff_fffd v1116 = uextend.i32 v1 v1161 = isub v376, v1116 ; v376 = 0xffff_fffd v1936 = rotl v59, v1161 return v1936 }
</details>
This testcase spends a huge amount of time in egraphs with this PR and it now fails where it didn't before. Although I'm not 100% sure this isn't a bug in one of the rules that wasn't discovered previously.
I'm going to look into this again later today
afonso360 edited a comment on issue #7465:
Hey, I ran the fuzzer on RISC-V overnight on this branch to check if there is something wrong with the RISC-V backend. I don't know if there is yet, but I think I got a reproduction of the issue that was happening in CI earlier.
<details>
<summary>Testcase</summary>;; Run test case test interpret test run set opt_level=speed_and_size target riscv64gc has_zca has_zcd function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { ss0 = explicit_slot 29 ss1 = explicit_slot 17 ss2 = explicit_slot 49 ss3 = explicit_slot 52 ss4 = explicit_slot 17 ss5 = explicit_slot 17 block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v54 -> v1 v37 = rotl v0, v10 v38 = rotl v37, v10 v39 = rotl v38, v10 v40 = rotl v39, v10 v41 = rotl v40, v10 v42 = rotl v41, v10 v43 = select_spectre_guard v1, v10, v10 v44 = bxor_not v43, v43 v55 -> v44 v45 = bitrev v42 v46 = sextend.i128 v45 v47 = rotl v45, v44 v48 = rotl v47, v44 v49 = select v48, v48, v48 v50 = rotl v49, v44 v51 = rotl v50, v44 v52 = rotl v51, v44 v53 = rotl v52, v44 v58 -> v53 v56 = select_spectre_guard.i32 v54, v55, v55 v57 = bxor_not v56, v56 v59 = bitrev.i8 v58 v61 = rotl v59, v57 v62 = rotl v61, v57 v63 = select v62, v62, v62 v64 = rotl v63, v57 v65 = rotl v64, v57 v66 = rotl v65, v57 v67 = rotl v66, v57 v68 = rotr v67, v54 v69 = rotl v68, v57 v70 = rotl v69, v57 v71 = rotl v70, v57 v72 = rotl v71, v57 v73 = rotl v72, v57 return v73 } ; run: %a(17, 4474, 4803839602528529, -10005959247738946646150328352768, 19070975, 281564249487374563584566874706289408, 8440, 0, 0, 0, 0, 0.0, 0) == 34
</details>
<details>
<summary>Egraphs Resultmain
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v91 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v91, v91 ; v91 = 0xffff_ffff, v91 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v82 = iadd v79, v10 v85 = iadd v82, v10 v88 = iadd v85, v10 v89 = rotl v0, v88 v45 = bitrev v89 v215 = iconst.i32 2 v217 = rotl v45, v215 ; v215 = 2 v59 = bitrev v217 v308 = uextend.i32 v1 v310 = isub v308, v215 ; v215 = 2 v311 = ineg v310 v404 = iconst.i32 0xffff_fffb v406 = iadd v311, v404 ; v404 = 0xffff_fffb v408 = rotl v59, v406 return v408 }
</details>
<details>
<summary>Egraphs Resultfix-egraph-union
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v251 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v251, v251 ; v251 = 0xffff_ffff, v251 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v93 = iadd v79, v10 v130 = iadd v10, v93 v176 = iadd v10, v130 v177 = rotl v0, v176 v45 = bitrev v177 v679 = iconst.i32 10 v681 = rotl v45, v679 ; v679 = 10 v59 = bitrev v681 v376 = iconst.i32 0xffff_fffd v1116 = uextend.i32 v1 v1161 = isub v376, v1116 ; v376 = 0xffff_fffd v1936 = rotl v59, v1161 return v1936 }
</details>
~This testcase spends a huge amount of time in egraphs with this PR and it now fails where it didn't before. Although I'm not 100% sure this isn't a bug in one of the rules that wasn't discovered previously.~
~I'm going to look into this again later today~
Edit: This ended up being a RISC-V bug, but I think it's still worth looking at the testcase, we now spend a bunch of time building values which I'm not sure is intended.
afonso360 edited a comment on issue #7465:
Hey, I ran the fuzzer on RISC-V overnight on this branch to check if there is something wrong with the RISC-V backend. I don't know if there is yet, but I think I got a reproduction of the issue that was happening in CI earlier.
<details>
<summary>Testcase</summary>;; Run test case test interpret test run set opt_level=speed_and_size target riscv64gc has_zca has_zcd function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { ss0 = explicit_slot 29 ss1 = explicit_slot 17 ss2 = explicit_slot 49 ss3 = explicit_slot 52 ss4 = explicit_slot 17 ss5 = explicit_slot 17 block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v54 -> v1 v37 = rotl v0, v10 v38 = rotl v37, v10 v39 = rotl v38, v10 v40 = rotl v39, v10 v41 = rotl v40, v10 v42 = rotl v41, v10 v43 = select_spectre_guard v1, v10, v10 v44 = bxor_not v43, v43 v55 -> v44 v45 = bitrev v42 v46 = sextend.i128 v45 v47 = rotl v45, v44 v48 = rotl v47, v44 v49 = select v48, v48, v48 v50 = rotl v49, v44 v51 = rotl v50, v44 v52 = rotl v51, v44 v53 = rotl v52, v44 v58 -> v53 v56 = select_spectre_guard.i32 v54, v55, v55 v57 = bxor_not v56, v56 v59 = bitrev.i8 v58 v61 = rotl v59, v57 v62 = rotl v61, v57 v63 = select v62, v62, v62 v64 = rotl v63, v57 v65 = rotl v64, v57 v66 = rotl v65, v57 v67 = rotl v66, v57 v68 = rotr v67, v54 v69 = rotl v68, v57 v70 = rotl v69, v57 v71 = rotl v70, v57 v72 = rotl v71, v57 v73 = rotl v72, v57 return v73 } ; run: %a(17, 4474, 4803839602528529, -10005959247738946646150328352768, 19070975, 281564249487374563584566874706289408, 8440, 0, 0, 0, 0, 0.0, 0) == 34
</details>
<details>
<summary>Egraphs Resultmain
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v91 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v91, v91 ; v91 = 0xffff_ffff, v91 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v82 = iadd v79, v10 v85 = iadd v82, v10 v88 = iadd v85, v10 v89 = rotl v0, v88 v45 = bitrev v89 v215 = iconst.i32 2 v217 = rotl v45, v215 ; v215 = 2 v59 = bitrev v217 v308 = uextend.i32 v1 v310 = isub v308, v215 ; v215 = 2 v311 = ineg v310 v404 = iconst.i32 0xffff_fffb v406 = iadd v311, v404 ; v404 = 0xffff_fffb v408 = rotl v59, v406 return v408 }
</details>
<details>
<summary>Egraphs Resultfix-egraph-union
</summary>function %a(i8 sext, i16, i64 sext, i128 uext, i64, i128 uext, i64 uext, i64 uext, i64 uext, i128 uext, i32 sext, f64, i64 sext) -> i8 fast { block0(v0: i8, v1: i16, v2: i64, v3: i128, v4: i64, v5: i128, v6: i64, v7: i64, v8: i64, v9: i128, v10: i32, v11: f64, v12: i64): v43 = select_spectre_guard v1, v10, v10 v251 = iconst.i32 0xffff_ffff v56 = select_spectre_guard v1, v251, v251 ; v251 = 0xffff_ffff, v251 = 0xffff_ffff v76 = iadd v10, v10 v79 = iadd v76, v10 v93 = iadd v79, v10 v130 = iadd v10, v93 v176 = iadd v10, v130 v177 = rotl v0, v176 v45 = bitrev v177 v679 = iconst.i32 10 v681 = rotl v45, v679 ; v679 = 10 v59 = bitrev v681 v376 = iconst.i32 0xffff_fffd v1116 = uextend.i32 v1 v1161 = isub v376, v1116 ; v376 = 0xffff_fffd v1936 = rotl v59, v1161 return v1936 }
</details>
~This testcase spends a huge amount of time in egraphs with this PR and it now fails where it didn't before. Although I'm not 100% sure this isn't a bug in one of the rules that wasn't discovered previously.~
~I'm going to look into this again later today~
Edit: This ended up being a RISC-V bug (#7491), but I think it's still worth looking at the testcase, we now spend a bunch of time building values which I'm not sure is intended.
fitzgen commented on issue #7465:
Thanks for digging into that @afonso360!
Last updated: Nov 22 2024 at 16:03 UTC