mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-11-21T13:54:18+11:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/24Mu IR Type checking2017-11-21T13:54:18+11:00Isaac Garianoisaac@ecs.vuw.ac.nzMu IR Type checkingThe Mu IR compiler currently will compile some invalid mu code, specifically I noticed the following invalid code successfully compiled (which were used in some of the tests) :
* a SHL/LSHR/ASHR instruction where the second argument is...The Mu IR compiler currently will compile some invalid mu code, specifically I noticed the following invalid code successfully compiled (which were used in some of the tests) :
* a SHL/LSHR/ASHR instruction where the second argument is not the same as the first (in the case of the test the first argument was int<64> and the second argument was an int<8>) (this code was generated in tes_shl and test_lshr).
* passing an int<64> as an argument to a C function expecting an int<32> (this was generated by test_pass_1arg_by_stack, and test_pass_2arg_by_stack)
In addition the compiler doesn't seem to check when you use an SSA variable whether it has been assigned to yet.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/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/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/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/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/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/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/28Name mangling in Zebu, unnamed MuEntity, global/local names2017-07-19T15:05:23+10:00Yi LinName mangling in Zebu, unnamed MuEntity, global/local namesCurrently Zebu makes assumptions about names, and mangles names in a way that is inconsistent and confusing. And it may be inconsistent to the spec.
These are some notes (I need to rethink on these):
* Zebu assumes local names, and man...Currently Zebu makes assumptions about names, and mangles names in a way that is inconsistent and confusing. And it may be inconsistent to the spec.
These are some notes (I need to rethink on these):
* Zebu assumes local names, and mangles it (if needed) in its own way. The spec requires all names used via API are global names (no mangling is needed)
* Zebu checks and transforms each name so the name does not include special character, and can be safely used in assembly
* Zebu assumes some entities such as `Block`, `MuFunction` have a name. These assumption may not be consistent with the spec (the spec requires top-level entities have names). This needs further check.
* Names that start with number is valid as name for a Mu entity, however the name may not be valid to be used directly in the assembly.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/63[aarch64] Register allocotar is allocated multiple destination arguments to t...2017-07-14T14:20:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[aarch64] Register allocotar is allocated multiple destination arguments to the same registerWhen trying to compile the following MUIR function (using `muc -r`
```
.funcdef foo <(int<128> int<128> int<128> int<128> int<128> int<128>)->(int<128>)>
{
entry(<int<128>>a0 <int<128>>a1 <int<128>>a2 <int<128>>a3 <int<128>>a4 <int<1...When trying to compile the following MUIR function (using `muc -r`
```
.funcdef foo <(int<128> int<128> int<128> int<128> int<128> int<128>)->(int<128>)>
{
entry(<int<128>>a0 <int<128>>a1 <int<128>>a2 <int<128>>a3 <int<128>>a4 <int<128>>a5):
RET a5
}
```
I get an error
```
INFO - emity/foo.S:44:10: error: unpredictable LDP instruction, Rt2==Rt
LDP X0 ,X0 ,[X29,#16]
```
After peephole optimization, the code contained the following:
```
TRACE - #40 LDP X0 ,X0 ,[X29,#16] define: [1103, 1104] uses: [58] pred: [39] succ: [41]
TRACE - #41 LDP X0 ,X1 ,[X29,#32] define: [1107, 1108] uses: [58] pred: [40] succ: [43]
```
The register alocator has allocated #1103 and #1104 both to X0, but hasn't broken the last load (X0 and X1 are the return registers, so the last LDP instruction loads the last stack argument and writes the return value).Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/9Bug: hybrid layout2017-07-12T10:49:36+10:00John ZhangBug: hybrid layoutHybrid may contain empty fixed part, in which case `backend::layout_struct` fails because `struct_align = 0`.Hybrid may contain empty fixed part, in which case `backend::layout_struct` fails because `struct_align = 0`.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/23[x86_64] shift operations may return wrong result if 2nd operand is larger th...2017-07-12T10:49:36+10:00Yi Lin[x86_64] shift operations may return wrong result if 2nd operand is larger than int8Shifting instructions in Mu require two operands of the same size, e.g. `Shl <int64> a b`, in which `a` and `b` are both `int64`.
However `shl`, `shr`, `sar` in x86_64 either takes a second operand in the `CL` register (8 bits), or a...Shifting instructions in Mu require two operands of the same size, e.g. `Shl <int64> a b`, in which `a` and `b` are both `int64`.
However `shl`, `shr`, `sar` in x86_64 either takes a second operand in the `CL` register (8 bits), or as a 8bits immediate. Current the instruction selector simply moves lower 8bits of `b` into `CL`, which may result in incorrect result. https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/34Emitting a 128-bit int constant to a P<Value>2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzEmitting a 128-bit int constant to a P<Value>Currently the functions `emit_ireg_value` and `emit_reg_value` in `aarch64/mod.rs` and `emit_reg` in `x86_64\inst_sel.rs` are unimplemented when the source value/tree_node is a `Constant::IntEx`.
This will cause a problem if you try and ...Currently the functions `emit_ireg_value` and `emit_reg_value` in `aarch64/mod.rs` and `emit_reg` in `x86_64\inst_sel.rs` are unimplemented when the source value/tree_node is a `Constant::IntEx`.
This will cause a problem if you try and and do a 128-bit UDIV/UREM/SREM/SDIV (it will call `unimplemented!()`)
E.g. compiling the following code will fail with 'panic not yet impelemented'
```
.funcdef foo<()->()>
{
entry():
%v = UREM <int<128>> <int<128>>1 <int<128>>1
RET
}
```
(but only when using `muc` with `-c` , it works when using `muc` with `-r` (this is probably a bug in `muc`, I will look into it).
I believe the simplest solution would be to have some way of combining two `P<Value>`s into one.
(Basically have a function that is the inverse of `split_int128`).
That way we could use the same code for `emit_ireg_ex` and then instead of returning a pair of `P<Value>`'s we return a `P<Value>` constructed by combining these two.
I release the reason for this bug is that I have modified run time entry points for UDIV/UREM/SREM/SDIV to take a int<128> arguments, and so we need to pass a single `P<Value>` to the call to `emit_runtime_entry`, wheras before when using int<64> arguments we were passing 2 `P<Value>`'s for each 128-bit integer.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/35x86-64 calling functions with int<128> arguments2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzx86-64 calling functions with int<128> argumentsI have unfortunately broken then x86-64 backend, I belive this is due to changing the call for UDIV/UREM/SREM/SDIV to pass 128-bit values instead of 64-bit ones.
Specifically when running the PySOM test I get the following error:
```
...I have unfortunately broken then x86-64 backend, I belive this is due to changing the call for UDIV/UREM/SREM/SDIV to pass 128-bit values instead of 64-bit ones.
Specifically when running the PySOM test I get the following error:
```
thread '<unnamed>' panicked at 'not yet implemented', src/compiler/backend/arch/x86_64/inst_sel.rs:2948
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
6: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_precall_convention
7: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_c_call_internal
8: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_runtime_entry
9: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_binop
10: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::instruction_select
11: <mu::compiler::backend::x86_64::inst_sel::InstructionSelection as mu::compiler::passes::CompilerPass>::visit_function
12: mu::compiler::passes::CompilerPass::execute
13: mu::compiler::Compiler::compile
14: mu::vm::vm::VM::make_boot_image_internal
15: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
16: fnc_40
17: main
18: __libc_start_main
19: _start
fatal runtime error: failed to initiate panic, error 5
```
It seems there is a bug in the x86-64 `emit_precall_convention` function, which I am unable to fix as I am unfamiliar with the x86 calling conventions.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/40Hand crafted Fib bundle compiling failure2017-07-12T10:49:35+10:00John ZhangHand crafted Fib bundle compiling failure## Description
When compiling a hand crafted FIbonacci performance measurement Mu bundle, Zebu fails with the following message yet Holstein succeeds:
```
TRACE - instsel on node#1103 (STORE NotAtomic (%m.c.v.b.irheadnxt #1090 = GETFIEL...## Description
When compiling a hand crafted FIbonacci performance measurement Mu bundle, Zebu fails with the following message yet Holstein succeeds:
```
TRACE - instsel on node#1103 (STORE NotAtomic (%m.c.v.b.irheadnxt #1090 = GETFIELDIREF (%m.c.v.b.irhead #1089 = GETIREF %m.c.v.b.head #1088) 2) NullRef)
TRACE - instsel on STORE
thread '<unnamed>' panicked at 'a struct type does not have a layout yet: BackendTypeInfo { size: 8, alignment: 8, struct_layout: None, elem_padded_size: None, gc_type: GCType { id: 2, alignment: 8, fix_size: 8, fix_refs: Some(Map { offsets: [0], size: 8 }), var_refs: None, var_size: None } }', src/compiler/backend/arch/x86_64/inst_sel.rs:4640
```
## Bug Reproduction
* Clone mu/mu-perf-benchmarks repository and checkout mu/mu-perf-benchmarks@b1893146bf95cd6cf8388cb44fd03d76de5401aa (`zebu_bug`) branch.
* Edit `example/zebu_bug.yml` and set the correct `MU_ZEBU` environment variable.
* run `example/zebu_bug.yml` with `python3 mubench local example/zebu_bug.yml`, and check the error log file `example/fib_mu_zebu.log`.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/43Compiled Exception table isn't created when using a shared mu library2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzCompiled Exception table isn't created when using a shared mu libraryCurrently the compiled exception table is constructed in `vm_resume`, however this is not run for shared librarys? (at least isn't in the test_rpython:throw_catch test).
We need to create this table (or update it) whenever we load in ne...Currently the compiled exception table is constructed in `vm_resume`, however this is not run for shared librarys? (at least isn't in the test_rpython:throw_catch test).
We need to create this table (or update it) whenever we load in new libraries generated by the compiler (but it must be done after the loading and relocation, so that the calls to dlysym get the correct address of callsite and catch labels).Yi LinYi Lin