mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-07-12T10:49:36+10:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/11VMOptions2017-07-12T10:49:36+10:00Yi LinVMOptionsWe need to allow Zebu to take options during initialisation.
* The initialisation function starts from `mu_fastimpl_new()` in `vm/api/api_impl/muvm.rs`.
* Arguments as a formatted string would suffice.
* Consider using Rust crates ...We need to allow Zebu to take options during initialisation.
* The initialisation function starts from `mu_fastimpl_new()` in `vm/api/api_impl/muvm.rs`.
* Arguments as a formatted string would suffice.
* Consider using Rust crates to manage command line options, such as [clap](https://crates.io/crates/clap).RPython benchmarksYi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/7Insert intermediate blocks for removing phi-node values2017-07-12T10:49:36+10:00Yi LinInsert intermediate blocks for removing phi-node valuesThe current implementation insert moves before branching. Instead, we should insert intermediate blocks between source and destination blocks, and put moves there. The current implementation insert moves before branching. Instead, we should insert intermediate blocks between source and destination blocks, and put moves there. RPython benchmarksYi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/92CPU frequency scaling may affect the performance regression test2017-11-21T09:45:39+11:00Zixian CaiCPU frequency scaling may affect the performance regression testhttps://gitlab.anu.edu.au/mu/mu-perf-benchmarks/issues/20
cc @igariano01https://gitlab.anu.edu.au/mu/mu-perf-benchmarks/issues/20
cc @igariano01https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/91Support for sel4-rumprun2019-03-25T13:08:19+11:00Yi LinSupport for sel4-rumprunhttps://gitlab.anu.edu.au/mu/mu-impl-fast/merge_requests/20 and https://gitlab.anu.edu.au/mu/mu-impl-fast/merge_requests/21 added some code to support Zebu running on sel4-rumprun. However, it does not run on sel4-rumprun yet, due to `ro...https://gitlab.anu.edu.au/mu/mu-impl-fast/merge_requests/20 and https://gitlab.anu.edu.au/mu/mu-impl-fast/merge_requests/21 added some code to support Zebu running on sel4-rumprun. However, it does not run on sel4-rumprun yet, due to `rodal` does not support sel4-rumprun.
The changes mainly address these issues:
* removed usage of dynamic libraries (`dlopen`, `dlsym`, etc) as sel4-rumprun does not support dynamic linking.
* rewrote some testcases to avoid using dynamic libraries.
* added feature guard `sel4-rumprun` for OS dependent code. Feature guard is used instead of OS guard as Rust does not correctly recognise sel4-rumprun.
* added feature guard `sel4-rumprun-target-side` for two-stage cross compilation.
Problems with the changes:
* it doesn't actually run on rumprun (`rodal` uses `dlsym`).
* the changes currently have massive code duplication instead of reusing OS/Target dependent code for Linux/x86_64. And duplicated code is not maintained when the original code changes.
* there is some hard-coded path for running Zebu on sel4-rumprun.
* using feature guard `[#cfg(feature = "sel4-rumprun")]` instead of a proper OS guard `[#cfg(target_os = "sel4-rumprun")]` makes OS dependent code quite unreadable. For example, for linux code, we have to do
```
[#cfg(not(feature = "sel4-rumprun))]
[#cfg(target_os = "linux")]
... // linux dependent code
```
* there is no document on how to setup environment and run Zebu on sel4-rumprun.
These should be addressed if we want to properly support Zebu on sel4-rumprun.Javad Ebrahimian Amirijavad.amiri@anu.edu.auJavad Ebrahimian Amirijavad.amiri@anu.edu.auhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/87Make IR debug output from Zebu compatible with muc2017-10-09T17:38:55+11:00Yi LinMake IR debug output from Zebu compatible with mucCurrently with `trace` level logging, Zebu outputs IR in its own format. We should make this compatible with the text form that `muc` uses (https://gitlab.anu.edu.au/mu/mu-tool-compiler/blob/master/UIR.g4)Currently with `trace` level logging, Zebu outputs IR in its own format. We should make this compatible with the text form that `muc` uses (https://gitlab.anu.edu.au/mu/mu-tool-compiler/blob/master/UIR.g4)https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/84Execution of RPySOM fails on Zebu2017-09-09T02:29:35+10:00Zixian CaiExecution of RPySOM fails on Zebuhttps://gitlab.anu.edu.au/mu/mu-impl-fast/builds/11957
Not sure whether the problem is in PyPy-mu or Zebu though.
Will have a look at this later.https://gitlab.anu.edu.au/mu/mu-impl-fast/builds/11957
Not sure whether the problem is in PyPy-mu or Zebu though.
Will have a look at this later.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/83Memory leak when running cargo test2017-08-25T15:30:26+10:00Yi LinMemory leak when running cargo testRunning cargo tests seems to have increasing memory usage over time. It is possible that there is some memory leak (significant). I probably should first check if the memory mmaped for the heap is deallocated properly.Running cargo tests seems to have increasing memory usage over time. It is possible that there is some memory leak (significant). I probably should first check if the memory mmaped for the heap is deallocated properly.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/82Compiling an infinite loop results in an infinite loop2017-09-01T12:29:56+10:00Isaac Garianoisaac@ecs.vuw.ac.nzCompiling an infinite loop results in an infinite loopCompiling the following simple code for an infinite loop, causes the compiler itself to go into an infinite loop:
```
.funcdef test_loop <()->()>
{
entry():
BRANCH loop()
loop():
BRANCH loop()
}
```
It o...Compiling the following simple code for an infinite loop, causes the compiler itself to go into an infinite loop:
```
.funcdef test_loop <()->()>
{
entry():
BRANCH loop()
loop():
BRANCH loop()
}
```
It outputs (on aarch64):
```
...
TRACE - code for test_loop:
TRACE - #0 .globl test_loop define: [] uses: [] pred: [] succ: []
TRACE - #1 .type test_loop, @function define: [] uses: [] pred: [] succ: []
TRACE - #2 test_loop: define: [] uses: [] pred: [] succ: []
TRACE - #3 .globl test_loop define: [] uses: [] pred: [] succ: []
TRACE - #4 .equiv test_loop, test_loop define: [] uses: [] pred: [] succ: []
TRACE - #5 .cfi_sections .eh_frame, .debug_frame define: [] uses: [] pred: [] succ: []
TRACE - #6 .cfi_startproc define: [] uses: [] pred: [] succ: []
TRACE - #7 test_loop.#1010:prologue: define: [] uses: [] pred: [] succ: []
TRACE - #8 STP X29,X30,[SP,#-16]! define: [62] uses: [58, 60, 62] pred: [] succ: [9]
TRACE - #9 MOV X29,SP define: [58] uses: [62] pred: [8] succ: [13]
TRACE - #10 .cfi_def_cfa X29, 16 define: [] uses: [] pred: [] succ: []
TRACE - #11 .cfi_offset X29, -16 define: [] uses: [] pred: [] succ: []
TRACE - #12 .cfi_offset X30, -8 define: [] uses: [] pred: [] succ: []
TRACE - #13 SUB SP,SP,#144 define: [] uses: [] pred: [9] succ: [14]
TRACE - #14 define: [] uses: [58, 38] pred: [13] succ: [15]
TRACE - #15 define: [] uses: [58, 40] pred: [14] succ: [16]
TRACE - #16 define: [] uses: [58, 42] pred: [15] succ: [17]
TRACE - #17 define: [] uses: [58, 44] pred: [16] succ: [18]
TRACE - #18 define: [] uses: [58, 46] pred: [17] succ: [19]
TRACE - #19 define: [] uses: [58, 48] pred: [18] succ: [20]
TRACE - #20 define: [] uses: [58, 50] pred: [19] succ: [21]
TRACE - #21 define: [] uses: [58, 52] pred: [20] succ: [22]
TRACE - #22 define: [] uses: [58, 54] pred: [21] succ: [23]
TRACE - #23 define: [] uses: [58, 56] pred: [22] succ: [24]
TRACE - #24 define: [] uses: [58, 116] pred: [23] succ: [25]
TRACE - #25 define: [] uses: [58, 118] pred: [24] succ: [26]
TRACE - #26 define: [] uses: [58, 120] pred: [25] succ: [27]
TRACE - #27 define: [] uses: [58, 122] pred: [26] succ: [28]
TRACE - #28 define: [] uses: [58, 124] pred: [27] succ: [29]
TRACE - #29 define: [] uses: [58, 126] pred: [28] succ: [30]
TRACE - #30 define: [] uses: [58, 128] pred: [29] succ: [31]
TRACE - #31 define: [] uses: [58, 130] pred: [30] succ: [33]
TRACE - #32 test_loop.__0.entry: define: [] uses: [] pred: [] succ: []
TRACE - #33 B test_loop.__0.loop define: [] uses: [] pred: [31] succ: [35]
TRACE - #34 test_loop.__0.loop: define: [] uses: [] pred: [] succ: []
TRACE - #35 B test_loop.__0.loop define: [] uses: [] pred: [33, 35] succ: [35]
TRACE - #36 .cfi_endproc define: [] uses: [] pred: [] succ: []
TRACE - #37 .globl test_loop:end define: [] uses: [] pred: [] succ: []
TRACE - #38 test_loop:end: define: [] uses: [] pred: [] succ: []
TRACE - #39 .size test_loop, test_loop:end-test_loop define: [] uses: [] pred: [] succ: []
TRACE -
INFO - ---finish---
INFO - ---CompilerPass Peephole Optimization for FuncVer t.#1010 #1010 of Func #1009---
TRACE - #9 MOV X29,SP define: [58] uses: [62] pred: [8] succ: [13]
TRACE - examining first inst 35 of block test_loop.__0.loop
...
```
And on x86-64:
```
...
TRACE - code for test_loop:
TRACE - #0 .globl test_loop define: [] uses: [] pred: [] succ: []
TRACE - #1 test_loop: define: [] uses: [] pred: [] succ: []
TRACE - #2 .globl test_loop define: [] uses: [] pred: [] succ: []
TRACE - #3 .equiv test_loop, test_loop define: [] uses: [] pred: [] succ: []
TRACE - #4 .cfi_startproc define: [] uses: [] pred: [] succ: []
TRACE - #5 test_loop.#1003:prologue: define: [] uses: [] pred: [] succ: []
TRACE - #6 pushq %RBP define: [20] uses: [24, 20] pred: [] succ: [9]
TRACE - #7 .cfi_def_cfa_offset 16 define: [] uses: [] pred: [] succ: []
TRACE - #8 .cfi_offset %RBP, -16 define: [] uses: [] pred: [] succ: []
TRACE - #9 movq %RSP,%RBP define: [24] uses: [20] pred: [6] succ: [11]
TRACE - #10 .cfi_def_cfa_register %RBP define: [] uses: [] pred: [] succ: []
TRACE - #11 addq $-48 ,%rsp define: [] uses: [] pred: [9] succ: [12]
TRACE - #12 define: [] uses: [24, 15] pred: [11] succ: [13]
TRACE - #13 define: [] uses: [24, 52] pred: [12] succ: [14]
TRACE - #14 define: [] uses: [24, 56] pred: [13] succ: [15]
TRACE - #15 define: [] uses: [24, 60] pred: [14] succ: [16]
TRACE - #16 define: [] uses: [24, 64] pred: [15] succ: [18]
TRACE - #17 test_loop.__0.entry: define: [] uses: [] pred: [] succ: []
TRACE - #18 jmp test_loop.__0.loop define: [] uses: [] pred: [16] succ: [20]
TRACE - #19 test_loop.__0.loop: define: [] uses: [] pred: [] succ: []
TRACE - #20 jmp test_loop.__0.loop define: [] uses: [] pred: [18, 20] succ: [20]
TRACE - #21 .cfi_endproc define: [] uses: [] pred: [] succ: []
TRACE - #22 .globl test_loop:end define: [] uses: [] pred: [] succ: []
TRACE - #23 test_loop:end: define: [] uses: [] pred: [] succ: []
TRACE -
INFO - ---finish---
INFO - ---CompilerPass Peephole Optimization for FuncVer t.#1003 #1003 of Func #1001---
TRACE - #9 movq %RSP,%RBP define: [24] uses: [20] pred: [6] succ: [11]
TRACE - examining first inst 20 of block test_loop.__0.loop
...
```
The last line repeats infinitely on both architectures.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/81GCC crate update produces warnings2017-08-22T14:06:47+10:00Isaac Garianoisaac@ecs.vuw.ac.nzGCC crate update produces warningsIt seems the GCC crate has been updated and so now building Zebu produces warnings:
```
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/src/gc/build.rs:26:5
|
26 | gcc::compile_library("libgc_clib_aarch64.a", &["sr...It seems the GCC crate has been updated and so now building Zebu produces warnings:
```
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/src/gc/build.rs:26:5
|
26 | gcc::compile_library("libgc_clib_aarch64.a", &["src/heap/gc/clib_aarch64.S"]);
| ^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(deprecated)] on by default
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/build.rs:39:5
|
39 | gcc::compile_library("libruntime_c.a", &["src/runtime/runtime_c_aarch64_sysv.c"]);
| ^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(deprecated)] on by default
```
I don't know what to replace `compile_library` with, perhaps expanding it out to a `gcc::Build` and passing the `-c` option?
(Note: their were more warnings but I fixed them).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/80IR checker fails to handle loading from weakref2017-08-19T17:05:55+10:00John ZhangIR checker fails to handle loading from weakref## Problem Description
The spec says that when loading from a weak reference field, the result will be a strong reference. My understanding is, if I'm loading from `iref<weakref<void>>`, it should result a `ref<void>`, rather than a `wea...## Problem Description
The spec says that when loading from a weak reference field, the result will be a strong reference. My understanding is, if I'm loading from `iref<weakref<void>>`, it should result a `ref<void>`, rather than a `weakref<void>`.
It seems that the static checker fails to correctly handles this conversion. So when I try to cast the loaded `ref<void>` to `ref<struct>`, it complains of an invalid cast.Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nzhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/79Error in test_commoninst_pin2017-08-18T17:02:41+10:00Yi LinError in test_commoninst_pinThe function defined in `test_commoninst_pin()` in `test_otherops.py` has a signature of `[uptr<void>, int<64>] -> [int<64>]`, but the entry block is supplied with 0 arguments. It currently causes the current `HEAD` on develop failed due...The function defined in `test_commoninst_pin()` in `test_otherops.py` has a signature of `[uptr<void>, int<64>] -> [int<64>]`, but the entry block is supplied with 0 arguments. It currently causes the current `HEAD` on develop failed due to a newly added check between function signature and the actual arguments.John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/78Collect performance data when doing CI2017-08-27T22:42:17+10:00Zixian CaiCollect performance data when doing CI1. We would like to get rid of docker container when running CI
2. We would like to add an extra stage before `rustfmt` to execute `mubench local <path_to_yml> --dump <path>` and archive the data.1. We would like to get rid of docker container when running CI
2. We would like to add an extra stage before `rustfmt` to execute `mubench local <path_to_yml> --dump <path>` and archive the data.Zixian CaiZixian Caihttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/77Invalid IR in python tests2017-08-24T23:41:16+10:00Isaac Garianoisaac@ecs.vuw.ac.nzInvalid IR in python testsThanks to my new IR validation (it's not complete yet)
I have found several casses of invalid ir:
* `test_otherops.py::test_select`: An EQ specified to be for int<64> but operands are actually int<8>
* `test_otherops.py::test_commonin...Thanks to my new IR validation (it's not complete yet)
I have found several casses of invalid ir:
* `test_otherops.py::test_select`: An EQ specified to be for int<64> but operands are actually int<8>
* `test_otherops.py::test_commoninst_pin`: the argument to a STORE is an int<64> but the specified type is int<8>
* `test_rpython_dict.py::test_rpython_dict_new_1,test_rpython_dict_lookup,test_rpython_dict_new_100,test_rpython_dict_update`: There is a TRUNC from int<64> to int<64>
* `test_rpysom.py` there is an EQ comparison that is labeled as operating on ref<@stt6(struct)>, but one of the arguments is actually a ref<@hyb0(hybrid)>
Interestingly I get errors non-deterministicly.
There are more errors, I will update the list as I go through them
Actually there are way more errors, perhaps someone else can fix them (use my new ir-validation branch).
Here is the log of tests that failed (they all use to pass):
```
test_rpython_compare.py <- util.py:169: test_rpython_int_ne_value PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_ne_one PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_eq_one PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_ge_value PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_ne_zero PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_zero PASSED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_1 FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_empty PASSED
test_rpython_dict.py <- util.py:169: test_rpython_dict_lookup FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_100 FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_update FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length2 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_append PASSED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length100 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_all10 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length1 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_all100 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_new_5 PASSED
test_rpython_list.py <- util.py:169: test_rpython_image_list_append FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_iter FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_new_empty PASSED
test_rpython.py <- util.py:169: test_throw FAILED
test_rpython.py <- util.py:169: test_find_min PASSED
test_rpython.py <- util.py:169: test_exception_stack_unwind FAILED
test_rpython.py <- util.py:169: test_partition_in_quicksort PASSED
test_rpython.py <- util.py:169: test_dtoa FAILED
test_rpython.py <- util.py:169: test_rpytarget_print_argv FAILED
test_rpython.py <- util.py:169: test_rpytarget_richards_measure_time FAILED
test_rpython.py <- util.py:169: test_float FAILED
test_rpython.py <- util.py:169: test_add PASSED
test_rpython.py <- util.py:169: test_linkedlist_reversal PASSED
test_rpython.py <- util.py:169: test_quicksort PASSED
test_rpython.py <- util.py:169: test_open_file_as_stream FAILED
test_rpython.py <- util.py:169: test_rpython_main FAILED
test_rpython.py <- util.py:169: test_nbody FAILED
test_rpython.py <- util.py:169: test_rpython_time_diff FAILED
test_rpython.py <- util.py:169: test_new_cmpeq PASSED
test_rpython.py <- util.py:169: test_rpython_print_number FAILED
test_rpython.py <- util.py:169: test_rpytarget_richards0 FAILED
test_rpython.py <- util.py:169: test_rpytarget_sha1sum FAILED
test_rpython.py <- util.py:169: test_new FAILED
test_rpython.py <- util.py:169: test_vec3prod PASSED
test_rpython.py <- util.py:169: test_make_boot_image_simple PASSED
test_rpython.py <- util.py:169: test_threadtran_fib PASSED
test_rpython.py <- util.py:169: test_rpython_rethrow FAILED
test_rpython.py <- util.py:169: test_rpython_helloworld FAILED
test_rpython.py <- util.py:169: test_arraysum PASSED
test_rpython.py <- util.py:169: test_rpython_print_time FAILED
test_rpython.py <- util.py:169: test_rpytarget_testdicts FAILED
test_rpython.py <- util.py:169: test_rpython_print_fmt FAILED
test_rpython.py <- util.py:169: test_linked_list FAILED
test_som.py <- util.py:169: test_RPySOM FAILED
```John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/76Loading from a ref2017-08-09T21:31:30+10:00Isaac Garianoisaac@ecs.vuw.ac.nzLoading from a refAccording to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work a...According to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work around I have allowed refs as well)
You also can't use 'refs' for any of the other memory instructions (store, getelementiref etc...) except ofcourse getiref.John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/75Bug: emiting instruction address fails at unknown struct layout2017-08-09T17:54:01+10:00John ZhangBug: emiting instruction address fails at unknown struct layout## Problem description
Zebu fails when compiling PyPy with the following error:
```
thread '<unnamed>' panicked at 'a struct type does not have a layout yet: BackendType { size: 0, alignment: 1, struct_layout: None, elem_size: None, gc_...## Problem description
Zebu fails when compiling PyPy with the following error:
```
thread '<unnamed>' panicked at 'a struct type does not have a layout yet: BackendType { size: 0, alignment: 1, struct_layout: None, elem_size: None, gc_type: GCType { id: 2490, alignment: 1, fix_size: 0, fix_refs: None, var_refs: None, var_size: None } }', src/compiler/backend/arch/x86_64/inst_sel.rs:5804
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:355
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:371
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:549
5: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:511
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:495
7: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_inst_addr_to_value_inner
8: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_inst_addr_to_value
9: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::instruction_select
10: <mu::compiler::backend::x86_64::inst_sel::InstructionSelection as mu::compiler::passes::CompilerPass>::visit_function
11: mu::compiler::passes::CompilerPass::execute
12: mu::compiler::Compiler::compile
13: mu::vm::vm::VM::make_boot_image_internal
14: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
15: fnc_1063
16: main
17: __libc_start_main
18: _start
fatal runtime error: failed to initiate panic, error 5
```https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/74Ref map generation is wrong2017-08-09T09:49:27+10:00Isaac Garianoisaac@ecs.vuw.ac.nzRef map generation is wrongThe GC appears to be generating incorrect refmaps for types, this is causing test_pypy to fail.
Specifically when dumping an instance of 'stt294' whose structure is:
```
2509@stt294 = Struct:
1213@stt55 = Struct:
121...The GC appears to be generating incorrect refmaps for types, this is causing test_pypy to fail.
Specifically when dumping an instance of 'stt294' whose structure is:
```
2509@stt294 = Struct:
1213@stt55 = Struct:
1214@stt56 = Struct:
1060@stt10 = Struct:
1037@stt3 = Struct:
1012@i64 = Int(64) +0
1032@ptrstt2 = UPtr(1033@stt2 = Struct("@stt2") ) +8
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+16
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+24
1003@i8 = Int(8) *+32
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) +40
1126@refhyb11 = Ref(1127@hyb11 = Hybrid("@hyb11") ) *+48
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+56
1003@i8 = Int(8) +64
1010@refhyb1 = Ref(1011@hyb1 = Hybrid("@hyb1")) *+72
1012@i64 = Int(64) +80
1010@refhyb1 = Ref(1011@hyb1 = Hybrid("@hyb1")) *+88
1012@i64 = Int(64) +96
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10")) *+104
1003@i8 = Int(8) *+112
1003@i8 = Int(8) +113
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) *+120
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) +128
```
(The last column indicates the offset, and a * indicates that Zebu is treating the value at that offset as a reference when dumping). The reported ref map for this type is '1110101011011100', this is clearly completley wrong.
This bug can be reproduced with the following C code (executing it causes a segfault as it tries to dump an object at location '0x101', due to misreading a field as a reference):
```
#include <math.h>
#include <stddef.h>
#include <stdint.h>
#include "muapi.h"
#include "mu-fastimpl.h"
#define G(id, ...) global_ ## id
#define L(id, ...) local_ ## id
MuVM* mvm;
MuCtx* ctx;
MuID G(0, int64_const);
MuID G(1);
MuID G(2, uptr_stt2_const);
MuID G(3, stt2);
MuID G(4);
MuID G(5, int8_const);
MuID G(6);
MuID G(7);
MuID G(8, stt2_cell);
MuID G(9, hyb11);
MuID G(10, hyb11_cell);
MuID G(11, hyb1);
MuID G(12, hyb1_cell);
MuID G(13, stt3);
MuID G(14, stt3_cell);
MuID G(15, stt10);
MuID G(16, stt10_cell);
MuID G(17, stt56);
MuID G(18);
MuID G(19);
MuID G(20, stt55);
MuID G(21);
MuID G(22, stt294);
MuID G(23);
MuID G(24, stt294_cell);
void build_bundle() {
MuIRBuilder* irbuilder = ctx->new_ir_builder(ctx);
G(0, int64_const) = irbuilder->gen_sym(irbuilder, "@int64_const");
G(1) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_int(irbuilder, G(1), 64);
irbuilder->new_const_int(irbuilder, G(0, int64_const), G(1), 1);
G(2, uptr_stt2_const) = irbuilder->gen_sym(irbuilder, "@uptr_stt2_const");
G(3, stt2) = irbuilder->gen_sym(irbuilder, "@stt2");
G(4) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_uptr(irbuilder, G(4), G(3, stt2));
irbuilder->new_const_null(irbuilder, G(2, uptr_stt2_const), G(4));
G(5, int8_const) = irbuilder->gen_sym(irbuilder, "@int8_const");
G(6) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_int(irbuilder, G(6), 8);
irbuilder->new_const_int(irbuilder, G(5, int8_const), G(6), 1);
G(7) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_void(irbuilder, G(7));
irbuilder->new_type_struct(irbuilder, G(3, stt2), (MuTypeNode[]){G(7)}, 1);
G(8, stt2_cell) = irbuilder->gen_sym(irbuilder, "@stt2_cell");
irbuilder->new_global_cell(irbuilder, G(8, stt2_cell), G(3, stt2));
G(9, hyb11) = irbuilder->gen_sym(irbuilder, "@hyb11");
irbuilder->new_type_struct(irbuilder, G(9, hyb11), (MuTypeNode[]){G(7)}, 1);
G(10, hyb11_cell) = irbuilder->gen_sym(irbuilder, "@hyb11_cell");
irbuilder->new_global_cell(irbuilder, G(10, hyb11_cell), G(9, hyb11));
G(11, hyb1) = irbuilder->gen_sym(irbuilder, "@hyb1");
irbuilder->new_type_struct(irbuilder, G(11, hyb1), (MuTypeNode[]){G(7)}, 1);
G(12, hyb1_cell) = irbuilder->gen_sym(irbuilder, "@hyb1_cell");
irbuilder->new_global_cell(irbuilder, G(12, hyb1_cell), G(11, hyb1));
G(13, stt3) = irbuilder->gen_sym(irbuilder, "@stt3");
irbuilder->new_type_struct(irbuilder, G(13, stt3), (MuTypeNode[]){G(1), G(4)}, 2);
G(14, stt3_cell) = irbuilder->gen_sym(irbuilder, "@stt3_cell");
irbuilder->new_global_cell(irbuilder, G(14, stt3_cell), G(13, stt3));
G(15, stt10) = irbuilder->gen_sym(irbuilder, "@stt10");
irbuilder->new_type_struct(irbuilder, G(15, stt10), (MuTypeNode[]){G(13, stt3)}, 1);
G(16, stt10_cell) = irbuilder->gen_sym(irbuilder, "@stt10_cell");
irbuilder->new_global_cell(irbuilder, G(16, stt10_cell), G(15, stt10));
G(17, stt56) = irbuilder->gen_sym(irbuilder, "@stt56");
G(18) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(18), G(15, stt10));
G(19) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(19), G(13, stt3));
irbuilder->new_type_struct(irbuilder, G(17, stt56), (MuTypeNode[]){G(15, stt10), G(18), G(18), G(6), G(19)}, 5);
G(20, stt55) = irbuilder->gen_sym(irbuilder, "@stt55");
G(21) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(21), G(9, hyb11));
irbuilder->new_type_struct(irbuilder, G(20, stt55), (MuTypeNode[]){G(17, stt56), G(21), G(18), G(6)}, 4);
G(22, stt294) = irbuilder->gen_sym(irbuilder, "@stt294");
G(23) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(23), G(11, hyb1));
irbuilder->new_type_struct(irbuilder, G(22, stt294), (MuTypeNode[]){G(20, stt55), G(23), G(1), G(23), G(1), G(18), G(6), G(6), G(19), G(19)}, 10);
G(24, stt294_cell) = irbuilder->gen_sym(irbuilder, "@stt294_cell");
irbuilder->new_global_cell(irbuilder, G(24, stt294_cell), G(22, stt294));
irbuilder->load(irbuilder);
}
MuValue get_global(MuID id) { return ctx->handle_from_global(ctx, id); }
MuValue get_const(MuID id) { return ctx->handle_from_const(ctx, id); }
void store_field(MuIRefValue object, int field, MuValue value) {
MuIRefValue field_ref = ctx->get_field_iref(ctx, object, field);
ctx->store(ctx, MU_ORD_NOT_ATOMIC, field_ref, value);
}
MuIRefValue get_field_iref(MuIRefValue object, int field) {
return ctx->get_field_iref(ctx, object, field);
}
int main() {
mvm = mu_fastimpl_new_with_opts("init_mu --aot-emit-dir=emit");
ctx = mvm->new_context(mvm);
build_bundle();
MuIRefValue stt294_cell = get_global(G(24, stt294_cell));
MuIRefValue hyb1_cell = get_global(G(12, hyb1_cell));
MuIRefValue stt10_cell = get_global(G(16, stt10_cell));
MuIRefValue stt3_cell = get_global(G(14, stt3_cell));
MuIRefValue hyb11_cell = get_global(G(10, hyb11_cell));
MuIRefValue int64_const = get_const(G(0, int64_const));
MuIRefValue int8_const = get_const(G(5, int8_const));
MuIRefValue uptr_stt2_const = get_const(G(2, uptr_stt2_const));
store_field(stt294_cell, 1, hyb1_cell);
store_field(stt294_cell, 2, int64_const);
store_field(stt294_cell, 3, hyb1_cell);
store_field(stt294_cell, 4, int64_const);
store_field(stt294_cell, 5, stt10_cell);
store_field(stt294_cell, 6, int8_const);
store_field(stt294_cell, 7, int8_const);
store_field(stt294_cell, 8, stt3_cell);
store_field(stt294_cell, 9, stt3_cell);
MuIRefValue stt55_part = get_field_iref(stt294_cell, 0);
//.const stt55_const<stt55> = {stt56_const hyb11_cell stt10_cell int8_const}
store_field(stt55_part, 1, hyb11_cell);
store_field(stt55_part, 2, stt10_cell);
store_field(stt55_part, 3, int8_const);
MuIRefValue stt56_part = get_field_iref(stt55_part, 0);
store_field(stt56_part, 1, stt10_cell);
store_field(stt56_part, 2, stt10_cell);
store_field(stt56_part, 3, int8_const);
store_field(stt56_part, 3, stt3_cell);
//.const stt55_const<stt55> = {stt56_const hyb11_cell stt10_cell int8_const}
MuIRefValue stt10_part = get_field_iref(stt56_part, 0);
MuIRefValue stt3_part = get_field_iref(stt10_part, 0);
store_field(stt3_part, 0, int64_const);
store_field(stt3_part, 1, uptr_stt2_const);
ctx->make_boot_image(ctx,
(MuID[]){G(0, int64_const), G(2, uptr_stt2_const), G(3, stt2), G(5, int8_const), G(8, stt2_cell), G(9, hyb11), G(10, hyb11_cell), G(11, hyb1), G(12, hyb1_cell), G(13, stt3), G(14, stt3_cell), G(15, stt10), G(16, stt10_cell), G(17, stt56), G(20, stt55), G(22, stt294), G(24, stt294_cell)}, 17,
NULL, NULL, NULL, NULL, NULL, 0, NULL, NULL, 0,
"test_ref_map");
}
```https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/71Error on undefined reference to asm when linking with Zebu's shared library2017-08-04T17:26:57+10:00Yi LinError on undefined reference to asm when linking with Zebu's shared libraryIt has been reported multiple times that linking with Zebu's shared library (`libmu.so`) on linux will result a failure with error message: 'undefined reference to asm'. I am not sure what causes this problem. But a workaround is setting...It has been reported multiple times that linking with Zebu's shared library (`libmu.so`) on linux will result a failure with error message: 'undefined reference to asm'. I am not sure what causes this problem. But a workaround is setting `CARGO_HOME` to a local directory such as `.` or `.cargo` instead of using the default cargo directory when building Zebu and when linking with `libmu.so`. Linking against Zebu's static library has no issue like this.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/70[x86_64] Unimplemented conversions2017-08-01T23:27:03+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[x86_64] Unimplemented conversionsWhen trying to run test_pypy.py on develop, for some reason I am know longer running out of memory, instead I get the following error:
```
thread '<unnamed>' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_se...When trying to run test_pypy.py on develop, for some reason I am know longer running out of memory, instead I get the following error:
```
thread '<unnamed>' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_sel.rs:1352
```
It seems that BITCAST, FPTRUNC and FPEXT are the only unimplemented conversion ops on x86-64.
This should be fixed (the aarch64 backend implements them by emitting single assembly instructions, hopefully there are equivalent instructions for x86-64).Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/69test_pypy.py2017-09-08T19:21:51+10:00Isaac Garianoisaac@ecs.vuw.ac.nztest_pypy.pyI noticed theres a new test in 'test_pypy.py', I tried running it on wolf, it took about 1.4 hours to run, and failed with the following output:
```
[platform:execute] make in /tmp/usession-mu-rewrite-21/mu_c_src
[platform:execute] /tmp...I noticed theres a new test in 'test_pypy.py', I tried running it on wolf, it took about 1.4 hours to run, and failed with the following output:
```
[platform:execute] make in /tmp/usession-mu-rewrite-21/mu_c_src
[platform:execute] /tmp/usession-mu-rewrite-21/mu_c_src/pypy-zebu_build
[62eb3] translation-task}
[Timer] Timings:
[Timer] annotate --- 1441.8 s
[Timer] rtype_lltype --- 826.3 s
[Timer] entrypoint_mu --- 0.7 s
[Timer] backendopt_lltype --- 479.9 s
[Timer] mutype_mu --- 554.5 s
[Timer] optimise_mu --- 3.5 s
[Timer] database_mu --- 187.3 s
[Timer] compile_mu --- 1629.5 s
[Timer] ===========================================
[Timer] Total: --- 5123.4 s
[translation:info] Error:
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 318, in main
drv.proceed(goals)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 632, in proceed
result = self._execute(goals, task_skip = self._maybe_skip())
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/taskengine.py", line 114, in _execute
res = self._do(goal, taskcallable, *args, **kwds)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 280, in _do
res = func()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 617, in task_compile_mu
return self.translator.mu_bdlgen.gen_boot_image(str(target_name))
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/mu/genmu.py", line 205, in gen_boot_image
raise CompilationError(r.out, r.err)
[translation:ERROR] CompilationError: CompilationError(out="""
""")
[translation] start debugger...
Traceback (most recent call last):
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/bin/rpython", line 20, in <module>
main()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 325, in main
debug(True)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 278, in debug
pdb_plus_show.start(tb)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 442, in start
fn(*args)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 25, in post_mortem
self.interaction(t.tb_frame, t)
File "/usr/lib/pypy/lib-python/2.7/pdb.py", line 210, in interaction
self.cmdloop()
File "/usr/lib/pypy/lib-python/2.7/cmd.py", line 109, in cmdloop
self.preloop()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 29, in preloop
raise NoTTY("Cannot start the debugger when stdout is captured.")
NoTTY: Cannot start the debugger when stdout is captured.
FAILED
===================================================================================== FAILURES =====================================================================================
____________________________________________________________________________________ test_PyPy _____________________________________________________________________________________
def wrapper():
if spawn_proc:
p = Process(target=test_fnc, args=tuple())
p.start()
p.join()
> assert p.exitcode == 0
E assert 1 == 0
E + where 1 = <Process(Process-1, stopped[1])>.exitcode
util.py:175: AssertionError
=========================================================================== 1 failed in 5164.72 seconds ============================================================================
```
Running the generated executable directly (`/tmp/usession-mu-rewrite-21/mu_c_src/pypy-zebu_build`) produces a segmentation fault with backtrace:
```
#0 0x0000ffffb7d73290 in get_registers () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#1 0x0000ffffb7d6805c in mu_gc::heap::gc::stack_scan::h26a4a4690b846a42 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#2 0x0000ffffb7d68a6c in mu_gc::heap::gc::sync_barrier::h3196f411d603f72d () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#3 0x0000ffffb7d65ae8 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::yieldpoint_slow::h2fb394023ad9d127 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#4 0x0000ffffb7d65da0 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::alloc_from_global::h478cb1b13041748b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#5 0x0000ffffb7d43420 in mu::runtime::mm::check_allocator::h6bc9d32f8fd3cb8b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#6 0x0000ffffb7d43a7c in mu::runtime::mm::allocate_hybrid::h5092de94762e09c0 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#7 0x0000ffffb7c866d4 in mu::vm::vm::VM::new_hybrid::hfabedf7ba309020c () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#8 0x0000ffffb7c8e314 in mu::vm::api::api_bridge::_forwarder__MuCtx__new_hybrid::h3d1a9eb1116a6bc2 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#9 0x000000000c1add5c in fnc_450 ()
```
Also on `doge` trying to run the test results in an error something like 'Trigerring GC while GC is disabled', which if I recall correctly means the heap has run out of space (i'm not sure how to change the test to give the heap more space...)https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/68SELECT on comparison of doubles panicked at 'not yet implemented'2017-07-21T15:44:42+10:00Javad Ebrahimian Amirijavad.amiri@anu.edu.auSELECT on comparison of doubles panicked at 'not yet implemented'The following IR code:
```rust
ssa! (($vm, $tester_name) <int1> cmp_res);
inst! (($vm, $tester_name) blk_entry_cmp:
cmp_res = CMPOP (CmpOp::EQ) result f64_2_local
);
ssa! (($vm, $teste...The following IR code:
```rust
ssa! (($vm, $tester_name) <int1> cmp_res);
inst! (($vm, $tester_name) blk_entry_cmp:
cmp_res = CMPOP (CmpOp::EQ) result f64_2_local
);
ssa! (($vm, $tester_name) <int64t> blk_entry_ret);
inst! (($vm, $tester_name) blk_entry_inst_select:
blk_entry_ret = SELECT cmp_res int64_pass_local int64_fail_local
);
inst! (($vm, $tester_name) blk_entry_inst_ret:
SET_RETVAL blk_entry_ret
);
```
panics with this output:
```
TRACE - instsel on node#1032 (SETRETVAL (int<64>(%blk_entry_ret #1030) = SELECT if (int<1>(%cmp_res #1028) = EQ double(%result #1026) double(2)) then int<64>(0) else int<64>(1)))
TRACE - instsel on SETRETVAL
TRACE - instsel on node#1031 (int<64>(%blk_entry_ret #1030) = SELECT if (int<1>(%cmp_res #1028) = EQ double(%result #1026) double(2)) then int<64>(0) else int<64>(1))
TRACE - instsel on SELECT
FAILED
failures:
---- test_compiler::test_floatingpoint::test_double_add stdout ----
thread 'test_compiler::test_floatingpoint::test_double_add' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_sel.rs:3790:32
```
Both `result` and `f64_2_local` are doubles.
I'm using a commit from 20/06/2017 on 5:19PM.
In the newest commit, this `unimplemented!()` panic in located at line 4433 of `x86_64/inst_sel.rs`.Yi LinYi Lin