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/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/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/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/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 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/53Exception Handling when arguments are passed on the stack2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzException Handling when arguments are passed on the stackWhen arguments are passed on the stack to a call whose exception-clause/catch-block is executed (due to an exception being thrown) the stack pointer is incorrectly restored. This can be demonstrated with the simple program:
```
.funcsig...When arguments are passed on the stack to a call whose exception-clause/catch-block is executed (due to an exception being thrown) the stack pointer is incorrectly restored. This can be demonstrated with the simple program:
```
.funcsig stack_sig = (int<64> int<64> int<64> int<64> int<64> int<64> int<64>)->()
.funcdef stack_args <stack_sig>
{
entry(<int<64>> v0 <int<64>> v1 <int<64>> v2 <int<64>> v3 <int<64>> v4 <int<64>> v5 <int<64>> v6):
THROW <ref<void>> NULL
}
.funcdef test_except_stack_args <main_sig>
{
entry(<int<32>>argc <uptr<uptr<char>>>argv):
CALL <stack_sig> stack_args(<int<32>>0 <int<32>>1 <int<32>>2 <int<32>>3 <int<32>>4 <int<32>>5 <int<32>>6)
EXC (exit(<int<32>> 0) exit(<int<32>> 1))
exit(<int<32>> status):
RET status
}
```
(testable with `pytest tests/test_muc/test_simple.py::test_except_stack_args`).
This segfaults on x86-64 (which only has 6 argument registers, so the call to stack_args passes some arguments to the stack), but it works as expected on aarch64 (which has 8 argument registers, so nothing is passed on the stack).Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nzhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/54[aarch64] Converting from floating-point overflow issue2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nz[aarch64] Converting from floating-point overflow issueCurrently the conversions from floating points (FPTOSI, FPTOUI) will only work correctly when there is an overflow (i.e. the source is larger or smaller than the largest/smallest values in the destination) for 32-bit and 64-bit, and 128-...Currently the conversions from floating points (FPTOSI, FPTOUI) will only work correctly when there is an overflow (i.e. the source is larger or smaller than the largest/smallest values in the destination) for 32-bit and 64-bit, and 128-bit (I should probably test this).
For other sizes it will just truncate the result of the 32-bit/64-bit operation, which will not produce the correct value if the floating point overflows the smaller type.Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nzhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/55Cannot drop a lock in `throw_exception_internal`2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzCannot drop a lock in `throw_exception_internal`In my latest commit, I have modified the structure of the exception table (so that it dosn't use unsafe pointers, and in order to fix Issue #53 ).
In `throw_exception_internal` I acquire a read lock the `compiled_callsite_table`, we wan'...In my latest commit, I have modified the structure of the exception table (so that it dosn't use unsafe pointers, and in order to fix Issue #53 ).
In `throw_exception_internal` I acquire a read lock the `compiled_callsite_table`, we wan't this lock to be realesed before calling `exception_restore`, however the borrow checker won't let me:
```
error[E0505]: cannot move out of `compiled_callsite_table` because it is borrowed
--> src/runtime/exception.rs:89:18
|
65 | let table_entry = compiled_callsite_table.get(&callsite);
| ----------------------- borrow of `compiled_callsite_table` occurs here
...
89 | drop(compiled_callsite_table); // drop the lock first
| ^^^^^^^^^^^^^^^^^^^^^^^ move out of `compiled_callsite_table` occurs here
```
So I have commented out line 89, and things seam to work.
The function `exception_restore` is marked as non-returning, so perhaps the rust compiler is smart enough to do the drop for us, if it isn't, we will get a deadlock if someone tries to acquire a write lock once an exception has been thrown (however currently we only modify the table once at startup, before any exceptions are thrown, so this won't occur).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/57Giving a weird name to a function dosn't work2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzGiving a weird name to a function dosn't workA test I added to test zebus name handling capabilities, which even after my addition of proper mangling, is failing strangely,
specifically the test run by `pytest tests/test_muc/test_simple.py::test_name`
which builds the bundle:
``...A test I added to test zebus name handling capabilities, which even after my addition of proper mangling, is failing strangely,
specifically the test run by `pytest tests/test_muc/test_simple.py::test_name`
which builds the bundle:
```
.global @-0.a5-1_5 <void>
.const @0 <int<32>> = 0
.funcdef @0-main.func <main_sig>
{
entry(<int<32>>%1.3 <uptr<uptr<char>>>%-):
RET @0
}
```
And creates an executable called `test_name` with the primordial function `0-main.func`.
When trying to compile it produces the following error:
```
TRACE - Linking boot image...
TRACE - functions: ["0-main.func", "primordial"]
TRACE - extern sources: []
TRACE - output : test_name
TRACE - copying from "/root/mu-impl-fast/src/runtime/main.c" to "emit/main.c"
INFO - output as "emit/test_name"
INFO - link with "emit/0-main.s"
INFO - link with "emit/primordial.s"
INFO - link with "emit/context.s"
INFO - link with "emit/main.c"
INFO - link with "/root/mu-impl-fast/target/release/libmu.a"
INFO - executing: "clang" "-ldl" "-lrt" "-lm" "-lpthread" "emit/0-main.s" "emit/primordial.s" "emit/context.s" "emit/main.c" "/root/mu-impl-fast/target/release/libmu.a" "-rdynamic" "-o" "emit/test_name"
INFO - ---out---
INFO -
INFO - ---err---
INFO - clang-4.0: error: no such file or directory: 'emit/0-main.s'
```
Where the name `0-main.func` came from is a complete mystery... (it seams to have chopped of the `.func` part of the functions name, but why??)Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nz