mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-07-12T10:49:35+10:00https://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/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/12Use sidemap for GC object metadata2017-11-21T13:48:32+11:00Yi LinUse sidemap for GC object metadataZebu intends to side maps to seperate objects from their metadata.
However, currently as a compromise, I am using a 64-bit object header along with `GCType` for the metadata. We will go back to using side maps.
This issue describ...Zebu intends to side maps to seperate objects from their metadata.
However, currently as a compromise, I am using a 64-bit object header along with `GCType` for the metadata. We will go back to using side maps.
This issue describes the design of sidemap scheme.
* we will assume a minimal object size `MIN_SIZE`, and a minimal alignment `MIN_ALIGN`. The larger the minimal size/align is, the less memory is required for metadata (see below). However, it wastes memory in the heap. MIN_SIZE of 16/24/32<del>bits</del> bytes, MIN_ALIGN of 128bits are reasonable.
* object metadata includes:
* 1bit/MIN_ALIGN: object start (and end - so we can decide size) (size is required for copying/dumping object)
* 1bit/64bits: reference locations
* 8bits/MIN_SIZE: gc state (mark bit, reference count, etc)
* small objects have less space to encode metadata, but large objects have plenty. We can use different schemes to encode small/large objects.
* side maps should be stored in the metadata part of a page/memory chunk.
More concrete design will be updated here once we discuss more. Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/14Tune instruction selection for mu code from RPython2017-07-12T10:49:36+10:00Yi LinTune instruction selection for mu code from RPythonThis issue tracks common instruction patterns that the RPython compiler generates.
We will need to tune instruction selector to generate efficient code for these patterns.
* [x] Conditional branch
`cmpres = CMP_OP a b`
`v1 = ZE...This issue tracks common instruction patterns that the RPython compiler generates.
We will need to tune instruction selector to generate efficient code for these patterns.
* [x] Conditional branch
`cmpres = CMP_OP a b`
`v1 = ZEXT <int1 int8> cmpres`
`v2 = CMP_EQ v1 1`
`BRANCH2 v2 ... ...`Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/47Trace scheduling2017-09-12T16:32:51+10:00Yi LinTrace schedulingIn fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra ju...In fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra jumps(unconditional or conditional).
[fib-zebu.s](/uploads/7c4e865b48b98ce298c7d65609763241/fib-zebu.s)[fib-c_O1.s](/uploads/3582548c5971039e669ffa73014a74a6/fib-c_O1.s)
Currently Zebu generates basic block trace based on probability. When the branching probability is 50% (by default), it pretty randomly picks blocks. We should have a pass with certain heuristics to generate trace.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/59Test suite with pytest writes to /tmp directory, which may cause issue about ...2017-08-24T23:40:47+10:00Yi LinTest suite with pytest writes to /tmp directory, which may cause issue about writing privilege.The tests in pytest will create files (executables/boot images, text files) in /tmp folder. This causes an issue when two users run the tests on a same machine: the first user creates executables in /tmp directory, and the second user do...The tests in pytest will create files (executables/boot images, text files) in /tmp folder. This causes an issue when two users run the tests on a same machine: the first user creates executables in /tmp directory, and the second user does not have privilege to overwrite the file, which causes the test fail.
A test should either create its own temp directory (and name it as code emitting directory for Zebu by using `--aot-emit-dir=<dir>`), or use the default *emit* directory under current directory and put all generated files there. Thus once the test is done, we can simply delete the specified folder, and next test run will be a fresh one. A test should not generate files in anywhere other than the specified directory, as this not only causes issue about writing privilege between users, but also gives a high possibility that we may accidentally run executables from previous test runs.John ZhangJohn Zhanghttps://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/30Single exit block for Mu function2017-07-20T15:39:12+10:00Yi LinSingle exit block for Mu functionWe should have a pass at IR level to rewrite the code to allow only one exit block so that the epilogue only appears once for each function.
Currently the compiler generates epilogue for each RET instruction.We should have a pass at IR level to rewrite the code to allow only one exit block so that the epilogue only appears once for each function.
Currently the compiler generates epilogue for each RET instruction.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 Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/36Replace TreeNode.clone_value() with TreeNode.as_value()2017-07-13T11:16:47+10:00Yi LinReplace TreeNode.clone_value() with TreeNode.as_value()we should avoid always cloning the `Value`.we should avoid always cloning the `Value`.Yi LinYi Linhttps://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/39Reduce serialised vm size (large bootimage size)2017-07-12T10:49:35+10:00Yi LinReduce serialised vm size (large bootimage size)For RPySOM interpreter, the boot image (executable) generated by Zebu is 175mb while the executable from the C backend is less than 1 mb. The main reason is that the Zebu's boot image contains a serialised vm (via Rust's serialisation),...For RPySOM interpreter, the boot image (executable) generated by Zebu is 175mb while the executable from the C backend is less than 1 mb. The main reason is that the Zebu's boot image contains a serialised vm (via Rust's serialisation), and I wasn't careful about what should be serialised so that basically everything is included. The serialised VM probably contribute to 99% of the boot image size.
I estimate if I am being careful about what should be serialised (only what will be used at runtime is worth serialising. #18 is part of the issue), the size can be reduced by at least 5-10 times.
And I am not sure how much this may contribute to the big performance slowdown.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/41persisting VM natively2017-07-12T10:49:35+10:00Yi Linpersisting VM nativelyWe now use Rust's `rustc_serialise` to persist VM as a JSON string in the boot image. This clearly imposes large overhead in both boot image size and loading time. We should persist the VM in a native and relocatable way.We now use Rust's `rustc_serialise` to persist VM as a JSON string in the boot image. This clearly imposes large overhead in both boot image size and loading time. We should persist the VM in a native and relocatable way.https://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/45mu-perf-benchmarks fib: movq $-2,%ECX2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzmu-perf-benchmarks fib: movq $-2,%ECXWhen trying to run my mu_fib_fast benchmark (`python3 -m mubench local ./example/test_mu_fib.yml`, in the latest version of mu-perf-benchmarks) on x86-64 I get the following errror:
```
INFO - executing: "clang" "example/fib_mu_fast-em...When trying to run my mu_fib_fast benchmark (`python3 -m mubench local ./example/test_mu_fib.yml`, in the latest version of mu-perf-benchmarks) on x86-64 I get the following errror:
```
INFO - executing: "clang" "example/fib_mu_fast-emit/mubench$cb_init.s" "example/fib_mu_fast-emit/mubench$cb_begin.s" "example/fib_mu_fast-emit/mubench$cb_end.s" "example/fib_mu_fast-emit/mubench$cb_report.s" "example/fib_mu_fast-emit/clockcb$tspec2dbl.s" "example/fib_mu_fast-emit/fib.s" "example/fib_mu_fast-emit/entry.s" "example/fib_mu_fast-emit/context.s" "example/fib_mu_fast-emit/main.c" "/home/isaacg/mu-impl-fast/target/release/libmu.a" "-ldl" "-lrt" "-lm" "-lpthread" "-rdynamic" "-o" "/root/mu-perf-benchmarks/example/fib-mu_fast"
INFO - ---out---
INFO -
INFO - ---err---
INFO - example/fib_mu_fast-emit/fib.s:44:11: error: invalid operand for instruction
movq $-1,%ECX
^~~~
example/fib_mu_fast-emit/fib.s:52:11: error: invalid operand for instruction
movq $-2,%ECX
^~~~
thread '<unnamed>' panicked at 'assertion failed: output.status.success()', src/testutil/mod.rs:41
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::testutil::exec
7: mu::testutil::aot::link_primordial
8: mu::vm::vm::VM::make_boot_image_internal
9: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
10: main
11: __libc_start_main
12: _start
fatal runtime error: failed to initiate panic, error 5
```
It ran without error on aarch64 (assuming johns code actually checks that fib produces the right result)Yi LinYi Linhttps://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/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/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/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 Zhang