Wasmtime GitHub notifications bot (Jun 15 2022 at 08:56): Wasmtime GitHub notifications bot (Jun 15 2022 at 08:56):yuyang-ok commented on issue #4271:
ci did not pass because I used is_riscv_feature_detected which is in std library.
Wasmtime GitHub notifications bot (Jun 15 2022 at 12:54):cfallin commented on issue #4271:
Hi @yuyang-ok -- thanks for this! I will take a detailed look next week when I'm back in the office. At a high level, my initial feedback is that new backends need to use ISLE for all instruction lowerings; we're working on migrating the others, and we don't want to create more work for ourselves by adopting a half-migrated backend. So, the
lower_inst.rsfile should be essentially empty (right now it has a bunch of handwritten lowerings). But now that you have a working backend, hopefully doing this is a bit easier than starting from scratch!
Wasmtime GitHub notifications bot (Jun 15 2022 at 21:48):yuyang-ok commented on issue #4271:
ok I will improve this.
Wasmtime GitHub notifications bot (Jun 15 2022 at 23:25):yuyang-ok commented on issue #4271:
@cfallin I didnot using isle to write a very much logic , I think isle is very good at match.turns out lower_inst.rs and isle.rs is quit large now!
Wasmtime GitHub notifications bot (Jun 21 2022 at 04:57):yuyang-ok commented on issue #4271:
@cfallin are you reviewing this?
Wasmtime GitHub notifications bot (Jun 21 2022 at 15:53):cfallin commented on issue #4271:
hi @yuyang-ok -- no, not yet; I just got back this morning. I would expect this to take some time, especially for a 21k-line PR.
At a high level, though, three questions:
My question about ISLE is I think still unanswered: are you planning to update this PR to use only ISLE lowering patterns, and not handwritten code? That is our standard for all new backend code and we cannot merge a new backend that uses the legacy approach.
Grepping for "todo" in this code, I still see a bunch of comments -- picking one example, "//todo what is this??" We unfortunately can't merge things like that (they are fine for draft PRs but not for production code): please make a pass through the PR and resolve all TODOs or uncertainties.
I think it would also be good to talk about ongoing expectations once a new backend is merged. I mentioned this in some earlier feedback as well, but: we want to make sure that every backend has some person or people who specialize in the architecture actively involved in the project. This is part of why I'm asking about your future plans: this PR is the start, but shouldn't be the only step. To this end, would you be willing to attend the Cranelift biweekly meeting at some point so we can talk about your new backend and plans?
Thanks for all your hard work on this so far!
Wasmtime GitHub notifications bot (Jun 21 2022 at 15:54):cfallin edited a comment on issue #4271:
hi @yuyang-ok -- no, not yet; I just got back this morning. I would expect this to take some time, especially for a 21k-line PR.
At a high level, though, three questions:
My question about ISLE is I think still unanswered: are you planning to update this PR to use only ISLE lowering patterns, and not handwritten code? That is our standard for all new backend code and we cannot merge a new backend that uses the legacy approach.
Grepping for "todo" in this code, I still see a bunch of comments -- picking one example, "//todo what is this??" We unfortunately can't merge things like that (they are fine for draft PRs but not for production code): please make a pass through the PR and resolve all TODOs or uncertainties.
I think it would also be good to talk about ongoing expectations once a new backend is merged. I mentioned this in some earlier feedback as well, but: we want to make sure that every backend has some person or people who specialize in the architecture actively involved in the project. This is part of why I'm asking about your future plans: this PR is the start, but shouldn't be the only step. To this end, would you be willing to attend the Cranelift biweekly meeting at some point so we can talk about your new backend and plans?
Thanks for all your hard work on this so far!
Wasmtime GitHub notifications bot (Jun 21 2022 at 23:25):yuyang-ok commented on issue #4271:
@cfallin I think it is fine to use ISLE to lowering inst instead of handwritten code, I think maybe the way I am using ISLE is not very good right now,I should doing this part of work after the review.
yes,software is never an one time job,software will evolve from time to time,I think at least I can maintain riscv64 backend, I am happy attend the Cranelift biweekly meeting at some point.
Wasmtime GitHub notifications bot (Jun 28 2022 at 05:02):yuyang-ok commented on issue #4271:
@cfallin I think need provides an extractor.
(decl value_inst(Inst)Value)
(extern extractor value_inst value_inst)
look like I will need them in "trapff" ... lowering.
So I can get compare parameters.
yuyang-ok commented on issue #4271:
@cfallin still waiting for you review. :)
Wasmtime GitHub notifications bot (Jul 02 2022 at 04:28):yuyang-ok edited a comment on issue #4271:
@cfallin still waiting for your review. :)
Wasmtime GitHub notifications bot (Jul 02 2022 at 04:41):cfallin commented on issue #4271:
@yuyang-ok unfortunately, I still have not gotten to it, sorry.
It looks like you still have code in legacy handwritten lowerings, though you're slowly moving it over to ISLE -- that's good, please keep doing that. I think it makes the most sense to review this PR once that is done.
LIkewise, I still see large blocks of commented-out code. As a random example, I see
// println!("xxxx : {}", buffer.disasm.unwrap()); let code = buffer.buffer.data(); // write_to_a_file("/home/yuyang/tmp/code.bin", code); //0: 000015b7 lui a1,0x1 //4: 23458593 addi a1,a1,564 # 0x1234 //8: 00b5053b addw a0,a0,a1 //c: 00008067Please carefully go over your code and remove anything you would not want merged into the main branch.
Regarding your continued pings: unfortunately, reviewing a 21,000-line PR is not a small task. It will probably take me a few days to a week to read through all of your code in detail. I have an enormous amount of work on my plate, with varying levels of priority. I also spent all last week with COVID and am still working through some backlog from that time away. So, I haven't gotten to this yet, and pinging me will not make the TODO list go faster.
While we very much appreciate the contribution -- having a RISC-V backend will be very valuable for Cranelift -- this process will require patience as well. Thanks!
Wasmtime GitHub notifications bot (Jul 02 2022 at 05:48):yuyang-ok commented on issue #4271:
@cfallin ok ,thanks,take care of yourself.
Wasmtime GitHub notifications bot (Jul 06 2022 at 01:52):yuyang-ok commented on issue #4271:
@cfallin ok.
Wasmtime GitHub notifications bot (Jul 06 2022 at 03:45):dunxen commented on issue #4271:
Hi @yuyang-ok, it's great that you've started the work on this, and thanks @cfallin for the mention. I do indeed have an interest in seeing this through.
I'll be able to give a thorough pass of this later today and throughout the rest of the week.
Wasmtime GitHub notifications bot (Jul 08 2022 at 01:24):yuyang-ok commented on issue #4271:
abi document I found it at https://github.com/riscv-non-isa/riscv-elf-psabi-doc
Wasmtime GitHub notifications bot (Jul 17 2022 at 22:28):yuyang-ok commented on issue #4271:
some part of wasmtime cannot compiler on target riscv64.
@cfallin @afonso360 @bjorn3 @bjorn3
Wasmtime GitHub notifications bot (Jul 18 2022 at 03:51):cfallin commented on issue #4271:
@yuyang-ok a port of
wasmtime's CPU-dependent bits -- the fiber library, and the trap handler details, at least -- would probably not be too much work beyond a pure Cranelift-only port, and is needed in any case for the port to be useful: otherwise, all we can do is exercise it with filetests. Enabling wasmtime on the platform allows us to run the Wasm test suite as well. So, yes, you've run into that missing support; would you be willing to build it? Or if not, perhaps another contributor could help?
Wasmtime GitHub notifications bot (Jul 18 2022 at 06:44):yuyang-ok commented on issue #4271:
@cfallin I like to give it a try.
Wasmtime GitHub notifications bot (Jul 25 2022 at 05:04):yuyang-ok commented on issue #4271:
can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.
Wasmtime GitHub notifications bot (Jul 25 2022 at 05:20):yuyang-ok edited a comment on issue #4271:
can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.
Wasmtime GitHub notifications bot (Jul 25 2022 at 08:29):afonso360 commented on issue #4271:
can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.I would suggest leaving that for a future PR. We can merge the backend independently and then start working on a port for wasmtime later. That would also make it a lot easier to review, since this is already a lot of code to review.
Wasmtime GitHub notifications bot (Jul 25 2022 at 08:30):afonso360 deleted a comment on issue #4271:
can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.I would suggest leaving that for a future PR. We can merge the backend independently and then start working on a port for wasmtime later. That would also make it a lot easier to review, since this is already a lot of code to review.
Wasmtime GitHub notifications bot (Aug 07 2022 at 07:42):yuyang-ok commented on issue #4271:
@cfallin is this project rely on v8,there are still some part not compile.
Wasmtime GitHub notifications bot (Aug 07 2022 at 08:49):bjorn3 commented on issue #4271:
If v8 doesn't support riscv, it should be fine to disable the fuzzers that check wasmtime against v8.
Wasmtime GitHub notifications bot (Aug 07 2022 at 08:49):bjorn3 edited a comment on issue #4271:
If v8 doesn't support riscv, it should be fine to disable the fuzzers that check wasmtime against v8 I think.
Wasmtime GitHub notifications bot (Aug 08 2022 at 00:53):yuyang-ok commented on issue #4271:
@cfallin @bjorn3 @afonso360 @afonso360 I think it's the time to review.I think I fix most of the problems.
Wasmtime GitHub notifications bot (Aug 08 2022 at 01:43):cfallin commented on issue #4271:
@cfallin @bjorn3 @afonso360 @afonso360 I think it's the time to review.I think I fix most of the problems.
@yuyang-ok I scanned through the diff at places where I had left comments before, and it looks like almost none of my comments have been addressed. Some of them are fairly small things, like formatting and typo fixes; others are more substantial, like "no commented-out code, please" or a general indication that some code needs to be cleaned up. Could you please address all of these comments, and then let us know when that is done?
Also, above (in this comment I see @dunxen expressed interest in making a clean-up pass over this PR. @dunxen, are you still willing to do this? If so, it seems that either after @yuyang-ok makes a pass or beforehand (coordinating with them as necessary) might be a good time for this. Thanks (and no worries if no longer able)!
I'm happy to see the qemu CI job added (does this mean Wasmtime fully works now?); I look forward to seeing this merged eventually, once it is cleaned up a bit!
Wasmtime GitHub notifications bot (Aug 08 2022 at 01:44):cfallin edited a comment on issue #4271:
@cfallin @bjorn3 @afonso360 @afonso360 I think it's the time to review.I think I fix most of the problems.
@yuyang-ok I scanned through the diff at places where I had left comments before, and it looks like almost none of my comments have been addressed. Some of them are fairly small things, like formatting and typo fixes; others are more substantial, like "no commented-out code, please" or a general indication that some code needs to be cleaned up. Could you please address all of these comments, and then let us know when that is done?
Also, above (in this comment) I see @dunxen expressed interest in making a clean-up pass over this PR. @dunxen, are you still willing to do this? If so, it seems that either after @yuyang-ok makes a pass or beforehand (coordinating with them as necessary) might be a good time for this. Thanks (and no worries if no longer able)!
I'm happy to see the qemu CI job added (does this mean Wasmtime fully works now?); I look forward to seeing this merged eventually, once it is cleaned up a bit!
Wasmtime GitHub notifications bot (Aug 08 2022 at 02:09):yuyang-ok commented on issue #4271:
@cfallin ok , I will do a full check.
Wasmtime GitHub notifications bot (Aug 08 2022 at 02:15):yuyang-ok commented on issue #4271:
wasmtime is not fully workd,because rusty_v8 cannot be compiler on riscv64.
Wasmtime GitHub notifications bot (Aug 08 2022 at 03:09):cfallin commented on issue #4271:
wasmtime is not fully workd,because rusty_v8 cannot be compiler on riscv64.
That's fine, as @bjorn3 mentions above V8 is only needed for one fuzzing target. You can disable it on riscv64.
Wasmtime GitHub notifications bot (Aug 08 2022 at 06:47):yuyang-ok commented on issue #4271:
why I cannot find all conversations.
some comment not show. why?
Wasmtime GitHub notifications bot (Aug 08 2022 at 07:15):yuyang-ok deleted a comment on issue #4271:
why I cannot find all conversations.
some comment not show. why?
Wasmtime GitHub notifications bot (Aug 08 2022 at 09:08):afonso360 commented on issue #4271:
Running
cargo test --target riscv64gc-unknown-linux-gnufrom the root of the repository it looks like we are also missing some other stuff for wasmtime, such as trampolines and trap handling.<details>
<summary>Output:</summary>error: unsupported architecture --> crates/runtime/src/trampolines.rs:55:9 | 55 | compile_error!("unsupported architecture"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unsupported architecture --> crates/runtime/src/traphandlers/backtrace.rs:46:9 | 46 | compile_error!("unsupported architecture"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unsupported platform --> crates/runtime/src/traphandlers/unix.rs:232:13 | 232 | compile_error!("unsupported platform"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: cannot find macro `wasm_to_libcall_trampoline` in this scope --> crates/runtime/src/libcalls.rs:100:17 | 100 | wasm_to_libcall_trampoline!($name ; [<impl_ $name>]); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 130 | wasmtime_environ::foreach_builtin_function!(libcall); | ---------------------------------------------------- in this macro invocation | = note: this error originates in the macro `libcall` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:227:9 | 227 | arch::assert_entry_sp_is_aligned(first_wasm_sp); | ^^^^ use of undeclared crate or module `arch` error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:230:13 | 230 | arch::assert_fp_is_aligned(fp); | ^^^^ use of undeclared crate or module `arch` error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:242:16 | 242 | if arch::reached_entry_sp(fp, first_wasm_sp) { | ^^^^ use of undeclared crate or module `arch` error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:252:18 | 252 | pc = arch::get_next_older_pc_from_fp(fp); | ^^^^ use of undeclared crate or module `arch` error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:258:24 | 258 | assert_eq!(arch::NEXT_OLDER_FP_FROM_FP_OFFSET, 0); | ^^^^ use of undeclared crate or module `arch` error[E0433]: failed to resolve: use of undeclared crate or module `arch` --> crates/runtime/src/traphandlers/backtrace.rs:260:57 | 260 | let next_older_fp = *(fp as *mut usize).add(arch::NEXT_OLDER_FP_FROM_FP_OFFSET); | ^^^^ use of undeclared crate or module `arch` error[E0308]: mismatched types --> crates/runtime/src/traphandlers/unix.rs:167:73 | 167 | unsafe fn get_pc_and_fp(cx: *mut libc::c_void, _signum: libc::c_int) -> (*const u8, usize) { | ------------- ^^^^^^^^^^^^^^^^^^ expected tuple, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression | = note: expected tuple `(*const u8, usize)` found unit type `()` Some errors have detailed explanations: E0308, E0433. For more information about an error, try `rustc --explain E0308`. error: could not compile `wasmtime-runtime` due to 11 previous errors warning: build failed, waiting for other jobs to finish...</details>
Wasmtime GitHub notifications bot (Aug 10 2022 at 00:26):yuyang-ok commented on issue #4271:
@afonso360 I will give a try to fix these.
Wasmtime GitHub notifications bot (Aug 11 2022 at 01:57):yuyang-ok commented on issue #4271:
a little update.
cranelift can pass test on riscv64.
@cfallin I think I resolved most of modify that you request.wasmtime test
test_successful_compilenot pass.
since I am not familiar with wasmtime's code . maybe still need some time to fix.
Wasmtime GitHub notifications bot (Aug 15 2022 at 05:17):yuyang-ok commented on issue #4271:
hey @cfallin @bjorn3 maybe need a little help here.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/as.20help.20about.20utf8_to_latin1.2E/near/293465163
Wasmtime GitHub notifications bot (Aug 15 2022 at 05:18):yuyang-ok edited a comment on issue #4271:
hey @cfallin @bjorn3 maybe need a little help here.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/as.20help.20about.20utf8_to_latin1.2E/near/293465163thanks. :-)
Wasmtime GitHub notifications bot (Aug 15 2022 at 06:55):yuyang-ok commented on issue #4271:
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?
Wasmtime GitHub notifications bot (Aug 15 2022 at 09:29):bjorn3 commented on issue #4271:
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?I think so.
Wasmtime GitHub notifications bot (Aug 16 2022 at 02:24):yuyang-ok commented on issue #4271:
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?I think so.
but I think I can't get if_frame_is_set_up at isle lowering stage. maybe I am not find the current function????
Wasmtime GitHub notifications bot (Aug 16 2022 at 02:24):yuyang-ok commented on issue #4271:
I think
iadd_ifcoutcan't be lowering.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/ask.20help.20for.20iadd_ifcout.2E/near/293648283
Wasmtime GitHub notifications bot (Aug 16 2022 at 03:01):yuyang-ok edited a comment on issue #4271:
I think
iadd_ifcoutcan't be lowered.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/ask.20help.20for.20iadd_ifcout.2E/near/293648283
Wasmtime GitHub notifications bot (Aug 16 2022 at 03:15):yuyang-ok edited a comment on issue #4271:
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?I think so.
but I think I can't get if_frame_is_set_up at isle lowering stage. maybe I am not find the correct function????
Wasmtime GitHub notifications bot (Aug 17 2022 at 07:17):afonso360 commented on issue #4271:
Yes, But My local qemu-riscv64 emulator doesn't implement it, I can't test it. right now I have two implemetion,
One rely on B extension , One don't.It's nice that we have both lowerings. Usually it's fine to select extensions in the runtest suite that the host does not implement. What we do is, at runtime check if the host has those features and skip them if they don't, so we could for example do something like:
target riscv64 target riscv64 has_bWhich would test both versions of the instruction. However it looks like we are missing
cranelift-nativesupport, and we can't implement that becauseis_riscv_feature_detected!is unstable.I'm not sure if there is a way around this, but it would be nice to test those instructions.
Wasmtime GitHub notifications bot (Aug 18 2022 at 03:39):yuyang-ok deleted a comment on issue #4271:
I think
iadd_ifcoutcan't be lowered.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/ask.20help.20for.20iadd_ifcout.2E/near/293648283
Wasmtime GitHub notifications bot (Aug 18 2022 at 06:08):yuyang-ok commented on issue #4271:
a little update. finally there is not
segfault. :-)
but still some test will fail.
Wasmtime GitHub notifications bot (Aug 18 2022 at 06:08):yuyang-ok edited a comment on issue #4271:
a little update. finally there is no
segfault. :-)
but still some test will fail.
Wasmtime GitHub notifications bot (Aug 18 2022 at 06:10):yuyang-ok edited a comment on issue #4271:
a little update. finally there is no
segfault. :-)
but still some test will fail.there are some feature not implemented , like
simd,atomic only implmented oni32andi64because on hardware supported.
Wasmtime GitHub notifications bot (Aug 21 2022 at 07:00):yuyang-ok commented on issue #4271:
Wasmtime GitHub notifications bot (Aug 26 2022 at 01:51):yuyang-ok commented on issue #4271:
https://gitlab.com/qemu-project/qemu/-/issues/1173
I am little confused by the
nan-boxed.
Wasmtime GitHub notifications bot (Aug 26 2022 at 01:54):yuyang-ok commented on issue #4271:
https://gitlab.com/qemu-project/qemu/-/issues/1173
I am little confused by the
nan-boxed.
Wasmtime GitHub notifications bot (Aug 26 2022 at 05:11):yuyang-ok commented on issue #4271:
Wasmtime GitHub notifications bot (Aug 26 2022 at 07:22):bjorn3 commented on issue #4271:
Left a comment on https://gitlab.com/qemu-project/qemu/-/issues/1173. It was incorrectly closed based on my reading of the riscv spec.
Wasmtime GitHub notifications bot (Aug 26 2022 at 07:22):bjorn3 edited a comment on issue #4271:
Left a comment on https://gitlab.com/qemu-project/qemu/-/issues/1173. Based on my reading of the riscv spec it was incorrectly closed.
Wasmtime GitHub notifications bot (Aug 26 2022 at 07:25):bjorn3 commented on issue #4271:
By the way which test is https://gitlab.com/qemu-project/qemu/-/issues/1178 for?
Wasmtime GitHub notifications bot (Aug 26 2022 at 15:58):bjorn3 commented on issue #4271:
So this isn't a qemu bug after all. https://gitlab.com/qemu-project/qemu/-/issues/1173#note_1079580087:
Ah, I see what you mean now. I am pretty sure this is the result of a bitcast from i32 -> f32 using FMV.D.X as move instead of FMV.W.X as required for 32bit floats. This is because f64 is passed as type at https://github.com/bytecodealliance/wasmtime/pull/4271/files#diff-6ce7e9721c05ddbf92ec1a5e11518e9833cd3f6c12d30f3131c4baf4d8ca2127R171-R172
Wasmtime GitHub notifications bot (Aug 28 2022 at 22:01):yuyang-ok commented on issue #4271:
By the way which test is https://gitlab.com/qemu-project/qemu/-/issues/1178 for?
related to https://gitlab.com/qemu-project/qemu/-/issues/1178
Wasmtime GitHub notifications bot (Aug 28 2022 at 22:22):yuyang-ok edited a comment on issue #4271:
By the way which test is https://gitlab.com/qemu-project/qemu/-/issues/1178 for?
related to https://gitlab.com/qemu-project/qemu/-/issues/1178
Wasmtime GitHub notifications bot (Aug 29 2022 at 07:55):yuyang-ok commented on issue #4271:
a little update.
test wast::Cranelift::spec::skip_stack_guard_page ... ok
failures:
failures:
memory::offsets_static_dynamic_oh_my
pooling_allocator::table_limit
wast::Cranelift::misc::memory64::simd
wast::Cranelift::misc::simd::almost_extmul
wast::Cranelift::misc::simd::canonicalize_nan
wast::Cranelift::misc::simd::cvt_from_uint
wast::Cranelift::misc::simd::issue_3173_select_v128
wast::Cranelift::misc::simd::issue_3327_bnot_lowering
wast::Cranelift::misc::simd::replace_lane_preserve
wast::Cranelift::misc::simd::spillslot_size_fuzzbug
wast::Cranelift::misc::simd::unaligned_load
wast::Cranelift::misc::simd::v128_select
test result: FAILED. 626 passed; 12 failed; 10 ignored; 0 measured; 0 filtered out; finished in 616.44s
error: test failed, to rerun pass '--test all'
Wasmtime GitHub notifications bot (Aug 29 2022 at 20:04):cfallin commented on issue #4271:
Getting very close, @yuyang-ok -- that's very exciting!
Wasmtime GitHub notifications bot (Aug 30 2022 at 01:46):yuyang-ok commented on issue #4271:
Wasmtime GitHub notifications bot (Aug 31 2022 at 00:37):yuyang-ok commented on issue #4271:
@cfallin @bjorn3 @afonso360 right now only simd test failed.
failures:
memory::offsets_static_dynamic_oh_my
wast::Cranelift::misc::memory64::simd
wast::Cranelift::misc::simd::almost_extmul
wast::Cranelift::misc::simd::canonicalize_nan
wast::Cranelift::misc::simd::cvt_from_uint
wast::Cranelift::misc::simd::issue_3173_select_v128
wast::Cranelift::misc::simd::issue_3327_bnot_lowering
wast::Cranelift::misc::simd::replace_lane_preserve
wast::Cranelift::misc::simd::spillslot_size_fuzzbug
wast::Cranelift::misc::simd::unaligned_load
wast::Cranelift::misc::simd::v128_select
test result: FAILED. 627 passed; 11 failed; 10 ignored; 0 measured; 0 filtered out; finished in 793.71s
Wasmtime GitHub notifications bot (Aug 31 2022 at 05:33):yuyang-ok commented on issue #4271:
@cfallin maybe another review?
Wasmtime GitHub notifications bot (Aug 31 2022 at 17:03):cfallin commented on issue #4271:
@yuyang-ok I'll give it another review sometime in the next week -- thank you very much for your patience and hard work here!
I will say overall that given that the backend passes tests for Wasm-MVP now, it's very likely we will be able to merge it; it's probably just a matter of some cleanup. We have precedent for disabling SIMD tests on platforms until SIMD is complete, so that should be fine.
Wasmtime GitHub notifications bot (Aug 31 2022 at 22:33):yuyang-ok commented on issue #4271:
@cfallin ok,thanks.
Wasmtime GitHub notifications bot (Sep 13 2022 at 20:00):cfallin commented on issue #4271:
@yuyang-ok I spent some time today going through this PR again. It's looking quite good overall; thank you again for the work!
I pushed a few fixups and a merge of the latest
mainto your branch. With this, I'm now happy with all the Rust code incranelift/codegen/src/isa/riscv64, and I'll take a look soon at the remainder.My main feedback now -- and I promise we're really close -- is:
The ISLE code has some strange formatting in places. I think I made some comments earlier about this, but it would be great if you could make a pass through it all and normalize it. Things like: spaces before opening parentheses (so
(decl term (A) B), not(decl term(A) B)), removing extraneous spaces otherwise (no((a b ) )), and putting closing parentheses on the same line.Maybe there is an autoformatter out there somewhere that can help; I haven't looked closely. Anyone else have ideas?
There are a few extractors like
iadd_ifcout_parametersthat serve to unwrap an instruction, just like(iadd_ifcout ...)would; it's unclear why they exist. Could you remove these or add comments noting why they are needed otherwise?If there are any other tests that don't pass, we need a completely clean CI run to merge. I went ahead and disabled SIMD tests in my changes I just pushed; it's fine to merge a backend initially without this, as long as there is a plan to add it eventually.
I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.
We should ensure that we fail cleanly on modules with SIMD, just like s390x did before it gained SIMD support.
And I think that's it! Let me know if anything above is unclear; happy to help further.
Wasmtime GitHub notifications bot (Sep 14 2022 at 00:29):yuyang-ok commented on issue #4271:
@cfallin That is true the ISLE formatting is strange.
I have aleardy remove extraneous spaces.
The reason I didn't pay much attention to ISLE formatting is that I am not very get used to the ISLE grammar.
I think maybe leave some space let me clearly to see where parenthesis starts and ends.I write like this deliberately.
(decl gen_float_round(FloatRoundOP Reg Type) Reg)
(rule
(gen_float_round op rs ty)
(let
(
(rd WritableReg (temp_writable_reg ty))
(tmp WritableReg (temp_writable_reg $I64))
(tmp2 WritableReg (temp_writable_reg $F64))
(_ Unit (emit (MInst.FloatRound op rd tmp tmp2 rs ty)))
)
(writable_reg_to_reg rd)
)
)
this makes me see the structure clearly. where add temporary variable and where to return.
`iadd_ifcout_parameters` is because of riscv has no iflags, I need extrac the inputs to generate overflow.
yuyang-ok edited a comment on issue #4271:
@cfallin That is true the ISLE formatting is strange.
I have aleardy remove extraneous spaces.
The reason I didn't pay much attention to ISLE formatting is that I am not very get used to the ISLE grammar.
I think maybe leave some space let me clearly to see where parenthesis starts and ends.I write like this deliberately.
(decl gen_float_round(FloatRoundOP Reg Type) Reg)
(rule
(gen_float_round op rs ty)
(let
(
(rd WritableReg (temp_writable_reg ty))
(tmp WritableReg (temp_writable_reg $I64))
(tmp2 WritableReg (temp_writable_reg $F64))
(_ Unit (emit (MInst.FloatRound op rd tmp tmp2 rs ty)))
)
(writable_reg_to_reg rd)
)
)
this makes me see the structure clearly. where add temporary variable and where to return.
`iadd_ifcout_parameters` is because of riscv has no iflags, I need extrac the inputs to generate overflow.
[inst.txt](https://github.com/bytecodealliance/wasmtime/files/9561637/inst.txt)
@cfallin this codestyle is ok??
cfallin commented on issue #4271:
I think maybe leave some space let me clearly to see where parenthesis starts and ends.
I write like this deliberately.
@yuyang-ok I'd prefer that we standardize on formatting. I agree that it can take a bit of work to get used to reading ISLE, as with any other language; but that's not a reason to do things differently in one part of the codebase vs somewhere else, IMHO. I also see some extra spaces in cases like this at the end of the line:
... (smulhi x y ))(the space aftery). It's not a huge deal, but I also don't want to loosen standards here without a good reason. Thanks!
iadd_ifcout_parametersis because of riscv has no iflags, I need extrac the inputs to generate overflow.The implementation here looks like it is equivalent to using
(iadd_ifcout x y)to get the args, and then getting the type ofx; so instead of writing(iadd_ifcout_parameters a b ty)here, you could write(iadd_ifcout a @ (value_type ty) b)instead. Then we can get rid of the custom extractors. Does that make sense?
Wasmtime GitHub notifications bot (Sep 14 2022 at 02:00):yuyang-ok commented on issue #4271:
@cfallin seens work to me. look like
ifcmp_parametersandffcmp_parametershave this problem too.
Wasmtime GitHub notifications bot (Sep 14 2022 at 03:19):yuyang-ok commented on issue #4271:
@cfallin I already remove
(smulhi x y ))iny.
Wasmtime GitHub notifications bot (Sep 14 2022 at 04:43):yuyang-ok commented on issue #4271:
@cfallin look like
offsets_static_dynamic_oh_myneed simd too.
test wast::Cranelift::spec::skip_stack_guard_page ... ok
failures:
failures:
memory::offsets_static_dynamic_oh_my
test result: FAILED. 626 passed; 1 failed; 32 ignored; 0 measured; 0 filtered out; finished in 752.18s
error: test failed, to rerun pass '--test all'
[1]+ 已完成 nohup ~/software/firefox/firefox-bin (工作目录: ~)
(当前工作目录：~/projects/wasmtime/tests)
Wasmtime GitHub notifications bot (Sep 14 2022 at 05:02):cfallin commented on issue #4271:
@cfallin look like
offsets_static_dynamic_oh_myneed simd too.```
test wast::Cranelift::spec::skip_stack_guard_page ... okfailures:
failures:
memory::offsets_static_dynamic_oh_mytest result: FAILED. 626 passed; 1 failed; 32 ignored; 0 measured; 0 filtered out; finished in 752.18s
error: test failed, to rerun pass '--test all'
[1]+ 已完成 nohup ~/software/firefox/firefox-bin (工作目录: ~)
(当前工作目录：~/projects/wasmtime/tests)
```It shouldn't, anymore: I excluded
v128loads from the test with the cfg directive intests/all/memory.rsin this commit. Have you pulled the changes that I pushed?
Wasmtime GitHub notifications bot (Sep 14 2022 at 05:07):yuyang-ok commented on issue #4271:
@cfallin I pulled your commit, only this test failed.
Wasmtime GitHub notifications bot (Sep 14 2022 at 05:18):cfallin commented on issue #4271:
Ah! OK, I do remember this failure, sorry; it gets past an earlier issue and now is hitting a
trapifthat is not lowered for some reason. It's not SIMD-related, I don't think. Here's what I see (cross-compiling from Ubuntu/aarch64 and running under emulation with qemu-risc64):---- memory::offsets_static_dynamic_oh_my stdout ---- thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9You'll probably need to look at what CLIF is being generated and make sure that the pattern is properly matched?
Wasmtime GitHub notifications bot (Sep 14 2022 at 05:18):cfallin edited a comment on issue #4271:
Ah! OK, I do remember this failure, sorry; it gets past an earlier issue and now is hitting a
trapifthat is not lowered for some reason. It's not SIMD-related, I don't think. Here's what I see (cross-compiling from Ubuntu/aarch64 and running under emulation with qemu-riscv64):---- memory::offsets_static_dynamic_oh_my stdout ---- thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9 thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9You'll probably need to look at what CLIF is being generated and make sure that the pattern is properly matched?
Wasmtime GitHub notifications bot (Sep 14 2022 at 06:12):yuyang-ok commented on issue #4271:
@cfallin ok, thanks. solved.
Wasmtime GitHub notifications bot (Sep 14 2022 at 06:58):yuyang-ok commented on issue #4271:
it this another qemu wrong implementation??
RUST_BACKTRACE=1 cargo test --target riscv64gc-unknown-linux-gnu --test host_segfault
Finished test [unoptimized + debuginfo] target(s) in 0.83s
Running tests/host_segfault.rs (/home/yuyang/projects/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/deps/host_segfault-0362e2365a90b3f7)
thread 'main' panicked at '
expected a stack overflow on hit async stack guard page with pooling allocator
got status: signal: 9 (SIGKILL)
', tests/host_segfault.rs:213:13
stack backtrace:
0: rust_begin_unwind
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
2: host_segfault::run_test
at ./tests/host_segfault.rs:213:13
3: host_segfault::main
at ./tests/host_segfault.rs:177:17
4: core::ops::function::FnOnce::call_once
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
error: test failed, to rerun pass '--test host_segfault'
I got a SIGKILL test on `host_segfault`.
yuyang-ok edited a comment on issue #4271:
it this another qemu wrong implementation??
RUST_BACKTRACE=1 cargo test --target riscv64gc-unknown-linux-gnu --test host_segfault
Finished test [unoptimized + debuginfo] target(s) in 0.83s
Running tests/host_segfault.rs (/home/yuyang/projects/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/deps/host_segfault-0362e2365a90b3f7)
thread 'main' panicked at '
expected a stack overflow on hit async stack guard page with pooling allocator
got status: signal: 9 (SIGKILL)
', tests/host_segfault.rs:213:13
stack backtrace:
0: rust_begin_unwind
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
1: core::panicking::panic_fmt
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
2: host_segfault::run_test
at ./tests/host_segfault.rs:213:13
3: host_segfault::main
at ./tests/host_segfault.rs:177:17
4: core::ops::function::FnOnce::call_once
at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
error: test failed, to rerun pass '--test host_segfault'
I got a SIGKILL test on `host_segfault`.
look like this test is not related cranelift at all,very likely related to `qemu-riscv64`.
yuyang-ok edited a comment on issue #4271:
Wasmtime GitHub notifications bot (Sep 15 2022 at 07:45):yuyang-ok edited a comment on issue #4271:
@cfallin I think all test in
wasmtime/testspassed except this one.
https://github.com/bytecodealliance/wasmtime/issues/4912I think there still have some codestyle problem in ISLE.
Wasmtime GitHub notifications bot (Sep 15 2022 at 11:24):afonso360 commented on issue #4271:
@cfallin is this project rely on v8,there are still some part not compile.
I took a look at why CI's not working. It looks like rusty_v8 does not produce precompiled binaries for riscv. I disabled it for riscv and CI now runs tests, but its failing somewhere. I've also added a build CI job for riscv.
See these two commits:
Wasmtime GitHub notifications bot (Sep 15 2022 at 11:24):afonso360 edited a comment on issue #4271:
@cfallin is this project rely on v8,there are still some part not compile.
I took a look at why CI's not working. It looks like rusty_v8 does not produce precompiled binaries for riscv. I disabled v8 for riscv and CI now runs tests, but its failing somewhere. I've also added a build CI job for riscv.
See these two commits:
Wasmtime GitHub notifications bot (Sep 15 2022 at 11:24):afonso360 edited a comment on issue #4271:
@cfallin is this project rely on v8,there are still some part not compile.
I took a look at why CI's not working. It looks like rusty_v8 does not produce precompiled binaries for riscv. I disabled v8 for riscv and CI now runs tests, but its failing somewhere. I've also added a CI build job for riscv.
See these two commits:
Wasmtime GitHub notifications bot (Sep 15 2022 at 11:44):afonso360 edited a comment on issue #4271:
@cfallin is this project rely on v8,there are still some part not compile.
I took a look at why CI's not working. It looks like rusty_v8 does not produce precompiled binaries for riscv. I disabled v8 for riscv and CI now runs tests, but its failing somewhere. I've also added a CI build job for riscv.
See these two commits:
Wasmtime GitHub notifications bot (Sep 16 2022 at 00:44):yuyang-ok commented on issue #4271:
@afonso360 ok, thanks a lot.
Wasmtime GitHub notifications bot (Sep 16 2022 at 01:48):yuyang-ok commented on issue #4271:
@cfallin I want disable
host_segfaulta little while due to https://github.com/bytecodealliance/wasmtime/issues/4912.
Wasmtime GitHub notifications bot (Sep 16 2022 at 05:11):yuyang-ok edited a comment on issue #4271:
@cfallin I want disable
host_segfaulta little while due to
https://gitlab.com/qemu-project/qemu/-/issues/1214
Wasmtime GitHub notifications bot (Sep 16 2022 at 06:56):yuyang-ok commented on issue #4271:
@cfallin
diff --git a/tests/host_segfault.rs b/tests/host_segfault.rs
index 7a761678b..616430289 100644
--- a/tests/host_segfault.rs
+++ b/tests/host_segfault.rs
@@ -144,6 +144,10 @@ fn main() {
},
true,
),
InstanceAllocationStrategy::pooling() trying to alloc more 6000G memory. Wasmtime GitHub notifications bot (Sep 16 2022 at 08:00):yuyang-ok edited a comment on issue #4271:
@cfallin
diff --git a/tests/host_segfault.rs b/tests/host_segfault.rs
index 7a761678b..6adac707e 100644
--- a/tests/host_segfault.rs
+++ b/tests/host_segfault.rs
@@ -144,6 +144,10 @@ fn main() {
},
true,
),
InstanceAllocationStrategy::pooling() trying to alloc more than 6000G memory space. Wasmtime GitHub notifications bot (Sep 20 2022 at 20:13):cfallin commented on issue #4271:
@yuyang-ok did you hit this error while using the patched qemu as our CI builds? (Start with qemu 6.1.0, then apply
ci/madvise.patch) If yes, and still an error, then we can disable the test temporarily. But I'd prefer not to if our patched qemu runs it properly.Otherwise, please go ahead and apply any other fixes (from Afonso above and any others needed) to get to green CI, make sure the other items in the list here are covered, and then ping me when ready -- thanks!
Wasmtime GitHub notifications bot (Sep 21 2022 at 00:43):yuyang-ok commented on issue #4271:
@cfallin I still hit this error using the patched qemu. I think we are ready.
Wasmtime GitHub notifications bot (Sep 22 2022 at 22:39):cfallin commented on issue #4271:
@cfallin I still hit this error using the patched qemu. I think we are ready.
Well, no, if tests don't pass then we aren't ready. We need to somehow either find and fix the issue or disable tests.
Going back to my checklist from my previous comment:
The ISLE code has some strange formatting in places. I think I made some comments earlier about this, but it would be great if you could make a pass through it all and normalize it. Things like: spaces before opening parentheses (so (decl term (A) B), not (decl term(A) B)), removing extraneous spaces otherwise (no ((a b ) )), and putting closing parentheses on the same line.
Maybe there is an autoformatter out there somewhere that can help; I haven't looked closely. Anyone else have ideas?
There are a few extractors like iadd_ifcout_parameters that serve to unwrap an instruction, just like (iadd_ifcout ...) would; it's unclear why they exist. Could you remove these or add comments noting why they are needed otherwise?
If there are any other tests that don't pass, we need a completely clean CI run to merge. I went ahead and disabled SIMD tests in my changes I just pushed; it's fine to merge a backend initially without this, as long as there is a plan to add it eventually.
I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.
We should ensure that we fail cleanly on modules with SIMD, just like s390x did before it gained SIMD support.
I see that
iadd_ifcout_parametersis now removed, so that's good, but can you confirm that you have addressed the other points, with comments or links to code you've added for each one?I also see some unresolved comments from long ago for simple things like typos in comments. Can you make sure there are no open code-review comments, and they are all addressed?
Once all of these things are done, then we can proceed!
Wasmtime GitHub notifications bot (Sep 22 2022 at 23:23):yuyang-ok commented on issue #4271:
@cfallin
(decl gen_div_by_zero(Reg)InstOutput)
(rule
(gen_div_by_zero r)
(gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero))
)
this codestyle remove all extra space will not ok.
must be like this???
(decl gen_div_by_zero(Reg)InstOutput)
(rule
(gen_div_by_zero r)
(gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero)))
yuyang-ok edited a comment on issue #4271:
@cfallin
(decl gen_div_by_zero(Reg)InstOutput)
(rule
(gen_div_by_zero r)
(gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero))
)
this codestyle remove all extra space will be not ok????
must be like this???
(decl gen_div_by_zero(Reg)InstOutput)
(rule
(gen_div_by_zero r)
(gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero)))
yuyang-ok commented on issue #4271:
I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.
Yes, this is becauseis_riscv64_feature_detectednot stable,I perfer not use it.
Wasmtime GitHub notifications bot (Sep 25 2022 at 02:34):yuyang-ok commented on issue #4271:
@cfallin I think we are ready.
Wasmtime GitHub notifications bot (Sep 25 2022 at 02:34):yuyang-ok edited a comment on issue #4271:
@cfallin I think we are ready.
Wasmtime GitHub notifications bot (Sep 25 2022 at 02:38):yuyang-ok edited a comment on issue #4271:
@cfallin I think we are ready.
maybe some part not appropriate like https://github.com/yuyang-ok/wasmtime/blob/risc-v/crates/wasmtime/src/engine.rs#L493 .
maybe you can help me a little??
Wasmtime GitHub notifications bot (Sep 26 2022 at 07:58):a1phyr commented on issue #4271:
I think you could do the same that for s390x, i.e. calling
getauxvalby yourself.You can find a RISC-V example in
std_detect(the implementation ofis_riscv64_feature_detected!) here.
Wasmtime GitHub notifications bot (Sep 26 2022 at 10:50):yuyang-ok commented on issue #4271:
I think you could do the same that for s390x, i.e. calling
getauxvalby yourself.You can find a RISC-V example in
std_detect(the implementation ofis_riscv64_feature_detected!) here.
still look a little hard to use to me. look like need useC???
Wasmtime GitHub notifications bot (Sep 26 2022 at 10:50):yuyang-ok edited a comment on issue #4271:
I think you could do the same that for s390x, i.e. calling
getauxvalby yourself.You can find a RISC-V example in
std_detect(the implementation ofis_riscv64_feature_detected!) [here](https://github.com/rust-lang/stdarch/blob/master/crates/std_detect/src/detect/os/linux/riscv.rs).
still look a little hard to use to me. look like need useC???
Wasmtime GitHub notifications bot (Sep 26 2022 at 10:50):yuyang-ok edited a comment on issue #4271:
I think you could do the same that for s390x, i.e. calling
getauxvalby yourself.
still look a little hard to use to me. look like need useC???
Wasmtime GitHub notifications bot (Sep 26 2022 at 10:50):yuyang-ok edited a comment on issue #4271:
I think you could do the same that for s390x, i.e. calling
getauxvalby yourself.still look a little hard to use to me. look like need use
C???
Wasmtime GitHub notifications bot (Sep 26 2022 at 11:10):yuyang-ok commented on issue #4271:
@cfallin what do you think appropriate to solve
is_riscv64_feature_detected???
Wasmtime GitHub notifications bot (Sep 27 2022 at 22:05):cfallin commented on issue #4271:
@cfallin what do you think appropriate to solve is_riscv64_feature_detected???
If we want to wait for stabilization of the feature-detection macro in the standard library, I don't see anything wrong with assuming a baseline RISC-V ISA level for now (in other words, running with no features ever detected). Does this seem reasonable or would it result in important optimizations going missing?
Wasmtime GitHub notifications bot (Sep 27 2022 at 22:59):yuyang-ok commented on issue #4271:
Does this seem reasonable or would it result in important optimizations going missing?
popcnt,ctz,rev8,brev8will fallback to loop implementation, seen reasonable to me, I think there instructions are used rare to me.
Wasmtime GitHub notifications bot (Sep 27 2022 at 23:33):yuyang-ok edited a comment on issue #4271:
Does this seem reasonable or would it result in important optimizations going missing?
popcnt,ctz,rev8,brev8will fallback to loop implementation, seen reasonable to me, I think these instructions are used rare to me.
Wasmtime GitHub notifications bot (Sep 28 2022 at 00:34):yuyang-ok commented on issue #4271:
@cfallin ok,thanks. :-)
Wasmtime GitHub notifications bot (Oct 08 2022 at 15:04):JhonnyRice commented on issue #4271:
@cfallin ok,thanks. :-)
Congratulations!
Wasmtime GitHub notifications bot (Nov 12 2022 at 13:02):martasp commented on issue #4271:
How can I use this feature, is there documentation?
How can I set a target risc5 and produce Linux risc5 elf binary?
I would want to use it like that:wasmtime exampleProgram.wasm --target risc5
Wasmtime GitHub notifications bot (Nov 12 2022 at 15:48):archanox commented on issue #4271:
This work is for RISC-V not risc5.
You'll likely need to useriscv64gcas per the changes in this PR.
Wasmtime GitHub notifications bot (Nov 12 2022 at 16:40):martasp commented on issue #4271:
I see that we have binaries riscv64gc here: https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.2 therefore It should probably work on riscv64 Linux. So I tried to install wasmtime in
riscv64Linux but without success.
Probably there is a difference betweenriscv64andriscv64gcbut I'm kinda new to these things, where can I learn it, any good resources?[root@localhost ~]# curl https://wasmtime.dev/install.sh -sSf | bash Error: Sorry! Wasmtime currently only provides pre-built binaries for x86_64 (Linux, macOS, Windows), aa rch64 (Linux, macOS), and s390x (Linux). [root@localhost ~]# uname Linux [root@localhost ~]# uname -p riscv64
Wasmtime GitHub notifications bot (Nov 12 2022 at 16:48):bjorn3 commented on issue #4271:
The script at https://wasmtime.dev/install.sh hasn't been updated yet for riscv64 support. You should probably directly download the binary from https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.2.
Last updated: Nov 22 2024 at 17:03 UTC