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/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.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/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/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/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/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/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/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/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/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/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/25Flags for int<128>2017-07-12T10:49:35+10:00Isaac Garianoisaac@ecs.vuw.ac.nzFlags for int<128>I have worked out what instructions should be emitted to compute flags for binary operations on Aarch64, on x86-64 a similar method of implementation should hopefully work. As such I have included my notes here.
```
Notes on notation:
...I have worked out what instructions should be emitted to compute flags for binary operations on Aarch64, on x86-64 a similar method of implementation should hopefully work. As such I have included my notes here.
```
Notes on notation:
The notation <exp> indicates exp is a 128-bit value
[exp] indicates exp is a 64-bits value
<[exp]> indicates exp is a 192-bits value
<<exp>> indicates exp is a 256-bits value
exp.h indicates the higher 64-bits of the expression and exp.l is the lower 64-bits of the expression
(each should occupy there own register)
Xi = 2^(64*i) (i.e. it is i*64-bits worth of zeros with a one at the front)
Ti is a temporary register (64-bits)
Note:
Some optimisations may be able to be performed if an argument to the instruction is an immediate
Zero and Negtaive Flags:
D, Z, N = BINOP S1, S2
ORR Z <- D.h, D.l // Z = D.h | D.l
CMP Z, #0 // Z <=> 0
CSET Z, EQ // Z = (Z == 0) ? 1 : 0
LSR N, D.h, 63 // N = (D.h >> 63) (so that N[0] = D.h[63])
Overflow and Carry for Add/Sub:
D, C, V = ADD/SUB S1, S2
// Compute the add/subtraction normal (except ensure the Ad with carry/subtract with carry sets the carry flag)
CSET C, CS // Set to 1 if the carry flag is set
// V[63] = 1 IFF D and S1 have different signs
EOR V <- D.h, S1.h // V = D.h ^ S1.h
For ADD:
// T[63] = 1 IFF S1 and S2 have different signs
EOR T1 <- S1h, S2.h // T1 = S1.h ^ S2.h
For Sub:
// T[63] = 1 IFF S1 and -S2 have different signs
EON T1 <- S1h, S2.h // T1 = S1.h ^ (~S2.h)
// V[63] = 1 iff D and S1 have different signs
// and S1 and S2 (or -S2) have the same sign
BIC V <- V, T // V = V & ~T
// Check tmp_status[n-1]
TST V, 1 << 63 // V[63] <=> 1
CSET V, NE // V = (V[63] != 1) ? 1 : 0
Overflow for Sbutraction: (Note: this is essentially the same method I used for arithmetic less than 32 bits)
D, V = SUB S1, S2
// Compute the subtraction normally
// V[63] = 1 IFF D and S1 have different signs
EOR V <- D.h, S1.h // V = D.h ^ S1.h
// V[63] = 1 iff D and S1 have different signs
// and S1 and -S2 have the same sign
BIC V <- V, T // V = V & ~T
// Check tmp_status[n-1]
TST V, 1 << 63 // V[63] <=> 1
CSET V, NE // V = (V[63] != 1) ? 1 : 0
------------
Overflow and carry for Multiply:
D, C, V = MUL S1, S2
---------------------- (this is just my working) ----------
<S1.h*X1+S1.l> * <S2.h*X1+S2.l> =
<<S1.h*S2.h*X2>> + <[S1.l*S2.h*X1]> + <[S1.h*X1*S2.l]> + <S1.l*S2.l>
Discared everything that occupys the lower 128-bits:
<<S1.h*S2.h*X2>> + <[S1.l*S2.h*X1]> + <[S1.h*X1*S2.l]>
-----------------------------
<S1.h*S2.h>*X2 +
<S1.l*S2.h>*X1 +
<S1.h*S2.l>*X1
--------------------------------
<[S1.h*S2.h].h*X1+[S1.h*S2.h].l*X1>*X2 +
<[S1.l*S2.h].h*X1 + [S1.l*S2.h.l>*X1
<[S1.h*S2.l].h*X1 + [S1.h*S2.l].l>*X1
--------------------------------------------------
[S1.h*S2.h].h*X3 + [S1.h*S2.h].l*X3 +
[S1.l*S2.h].h*X2 + [S1.l*S2.h.l*X1 +
[S1.h*S2.l].h*X2 + [S1.h*S2.l].l*X1
----------------------------------------------------
Discare all factors of X1 (as they will only contribute to the lower 128 bits of the result)
[[S1.h*S2.h].h+ [S1.h*S2.h].l]*X3 +
[[S1.l*S2.h].h + [S1.h*S2.l].h]*X2
So to get the overflow flag let:
D.h = [[S1.h*S2.h].h+ [S1.h*S2.h].l]
D.l = [[S1.l*S2.h].h + [S1.h*S2.l].h]
Then set it to '1' iff (D.h != 0) || (D.l != 0)
------------------------------------------
SO EMIT THE FOLLOWING CODE:
UMULH D.l <- S1.l, S2.h // D.l = [S1.l*S2.h].h
UMULH D.h <- S1.h*S2.l // D.h = [S1.h*S2.l].h
ADD D.l <- D.h, D.l // D.l += D.h
UMULH D.h <- S1.h, S2.h // D.h = [S1.h*S2.h].h
MADD D.h <- S1.h, S2.h, D.h // D.h += [S1.h*S2.h].l
CMP D.l, #0 // D.l <=> 0
CSET C <- NE // C = (D.l != 0) ? 1 : 0
CMP D.h, #0 // D.h <=> 0
CSINC C <- C, XZR, EQ // C = (D.h == 0) ? C : (0+1)
MOV V <- C // V = C (they should be the same)
// Now get the lower 128-bits of the product (and store it in D.h, D.l)
```https://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/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/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/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/7Insert intermediate blocks for removing phi-node values2017-07-12T10:49:36+10:00Yi LinInsert intermediate blocks for removing phi-node valuesThe current implementation insert moves before branching. Instead, we should insert intermediate blocks between source and destination blocks, and put moves there. The current implementation insert moves before branching. Instead, we should insert intermediate blocks between source and destination blocks, and put moves there. RPython benchmarksYi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/5JIT Tests2017-07-12T10:49:36+10:00John ZhangJIT TestsA list of tests to do for the JIT.
## Milestone Tests
- [x] constant function
- [x] fibonacci
- [x] two functions (compiling multiple functions)
- [x] RPython SHA1 test
- [ ] RPython GC benchmark
- [x] RPython Richards benchmark
- [x] ...A list of tests to do for the JIT.
## Milestone Tests
- [x] constant function
- [x] fibonacci
- [x] two functions (compiling multiple functions)
- [x] RPython SHA1 test
- [ ] RPython GC benchmark
- [x] RPython Richards benchmark
- [x] RPython NBody benchmark
- [x] RPython SOM interpreter
- [ ] PyPy interpreter with minimum modules
- [ ] PyPy interpreter with compilable modules
## Binary operation tests
- [x] `ADD`
- [x] `SUB`
- [x] `MUL`
- [x] `SDIV`
- [x] `UREM`
- [x] `SHL`
- [x] `LSHR`
- [x] `AND`
- [x] `XOR`
## Compare operation tests
- [x] `EQ`
- [x] `NE`
- [x] `SGE`
- [x] `SGT`
- [x] `SLE`
- [x] `SLT`
## Conversion operation tests
- [x] `TRUNC`
- [x] `ZEXT`
- [x] `SEXT`
- [x] `REFCAST`
- [x] `PTRCAST`
## Control flow operation tests
- [x] `BRANCH`
- [x] `BRANCH2`
- [x] `CALL`
- [x] `RET`
- [x] `SWITCH`
- [x] `CCALL`
- [x] `THROW`
## Memory operation tests
- [x] `NEW`
- [x] `NEWHYBRID`
- [x] `GETIREF`
- [x] `GETFIELDIREF`
- [x] `SHIFTIREF`
- [x] `GETVARPARTIREF`
- [x] `LOAD`
- [x] `STORE`
## `COMMINST` tests
- [x] `COMMINST @uvm.thread_exit`
- [x] `COMMINST @uvm.native.pin`
- [x] `COMMINST @uvm.native.unpin`
- [x] `COMMINST @uvm.get_threadlocal`
- [x] `COMMINST @uvm.set_threadlocal`John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/4IR Instruction Implementation2017-07-12T10:49:36+10:00John ZhangIR Instruction ImplementationA list of IR Instruction needed progressively.
Tick them off as you go, and watch for updates.
## IR Instructions
- [x] `ADD`
- [x] `SUB`
- [x] `MUL`
- [x] `SDIV`
- [x] `UDIV`
- [x] `SREM`
- [x] `UREM`
- [x] `SHL`
- [x] `ASHR`
- [x] `L...A list of IR Instruction needed progressively.
Tick them off as you go, and watch for updates.
## IR Instructions
- [x] `ADD`
- [x] `SUB`
- [x] `MUL`
- [x] `SDIV`
- [x] `UDIV`
- [x] `SREM`
- [x] `UREM`
- [x] `SHL`
- [x] `ASHR`
- [x] `LSHR`
- [x] `FADD`
- [x] `FSUB`
- [x] `FDIV`
- [x] `FMUL`
- [x] `AND`
- [x] `OR`
- [x] `XOR`
- [x] `EQ`
- [x] `NE`
- [x] `SGE`
- [x] `SGT`
- [x] `SLE`
- [x] `SLT`
- [x] `ULE`
- [x] `ULT`
- [x] `FOEQ`
- [x] `FOGT`
- [x] `FOLE`
- [x] `FOLT`
- [x] `FONE`
- [x] `TRUNC`
- [x] `ZEXT`
- [x] `SEXT`
- [x] `REFCAST`
- [x] `PTRCAST`
- [x] `FPTOSI`
- [x] `SITOFP`
- [x] `UITOFP`
- [x] `SELECT`
- [x] `BRANCH`
- [x] `BRANCH2`
- [x] `SWITCH`
- [x] `CALL`
- [x] `RET`
- [x] `NEW`
- [x] `NEWHYBRID`
- [x] `GETIREF`
- [x] `GETFIELDIREF`
- [x] `GETELEMIREF`
- [x] `SHIFTIREF`
- [x] `GETVARPARTIREF`
- [x] `LOAD`
- [x] `STORE`
- [x] `CCALL`
- [x] `NEWTHREAD`
- [x] `COMMINST @uvm.thread_exit`
- [x] `THROW`
- [x] `COMMINST @uvm.native.pin`
- [x] `COMMINST @uvm.native.unpin`
- [ ] `COMMINST @uvm.get_threadlocal`
- [x] `COMMINST @uvm.set_threadlocal`
Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/3API Implementation2017-07-12T10:49:36+10:00John ZhangAPI ImplementationBelow is the list of API calls to implement, ordered by priority derived from requirements from test cases.
Please tick them off as you go, and watch for updates.
## `MuIRBuilder`
- [x] `load`
- [x] `gen_sym`
- [x] `new_bb`
- [x] `new_...Below is the list of API calls to implement, ordered by priority derived from requirements from test cases.
Please tick them off as you go, and watch for updates.
## `MuIRBuilder`
- [x] `load`
- [x] `gen_sym`
- [x] `new_bb`
- [x] `new_binop`
- [x] `new_branch`
- [x] `new_branch2`
- [x] `new_call`
- [x] `new_ccall`
- [x] `new_cmp`
- [x] `new_comminst`
- [x] `new_const_double`
- [x] `new_const_extern`
- [x] `new_const_int`
- [x] `new_const_int_ex`
- [x] `new_const_null`
- [x] `new_conv`
- [x] `new_dest_clause`
- [x] `new_exc_clause`
- [x] `new_func`
- [x] `new_func_ver`
- [x] `new_funcsig`
- [x] `new_getfieldiref`
- [x] `new_getiref`
- [x] `new_getvarpartiref`
- [x] `new_global_cell`
- [x] `new_load`
- [x] `new_new`
- [x] `new_newhybrid`
- [x] `new_ret`
- [x] `new_select`
- [x] `new_shiftiref`
- [x] `new_store`
- [x] `new_switch`
- [x] `new_throw`
- [x] `new_type_double`
- [x] `new_type_float`
- [x] `new_type_funcref`
- [x] `new_type_hybrid`
- [x] `new_type_int`
- [x] `new_type_iref`
- [x] `new_type_ref`
- [x] `new_type_struct`
- [x] `new_type_ufuncptr`
- [x] `new_type_uptr`
- [x] `new_type_void`
## MuCtx
- [x] `store`
- [x] `get_field_iref`
- [x] `get_iref`
- [x] `get_var_part_iref`
- [x] `handle_from_const`
- [x] `handle_from_func`
- [x] `handle_from_global`
- [x] `handle_from_sint64`
- [x] `handle_from_uint64`
- [x] `handle_from_uint8`
- [x] `id_of`
- [x] `new_fixed`
- [x] `new_hybrid`
- [x] `new_ir_builder`
- [x] `refcast`
- [x] `shift_iref`Kunshan WangKunshan Wang