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/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/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/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/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/38Allocation Performance2017-11-21T13:37:05+11:00John ZhangAllocation Performance## Description
Measured allocation performance using following code with `n=10`:
```python
class A:
pass
def alloc(n):
for i in range(n):
a = A()
def target(driver, args):
...
def main(argv):
...
...## Description
Measured allocation performance using following code with `n=10`:
```python
class A:
pass
def alloc(n):
for i in range(n):
a = A()
def target(driver, args):
...
def main(argv):
...
for i in range(iterations):
cb.begin()
for j in range(1000000):
alloc(n)
cb.end()
cb.report(resfile)
return 0
```
Mean of measured results:
| stack | result|
| ----- | ----- |
| RPython Mu Zebu | 0.00072474 |
| RPython C `clang -O0` | 0.00432998 |
| RPython C `clang -O1` | 0.0000008 |https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/56Allow GC heap growth2017-11-21T13:35:56+11:00Yi LinAllow GC heap growthIn current GC implementation, we allocate memory of the given heap size, and allocate (and initialize) metadata for the whole heap all at once at startup. This causes heap initialization extremely slow (causing 70% of the startup time - ...In current GC implementation, we allocate memory of the given heap size, and allocate (and initialize) metadata for the whole heap all at once at startup. This causes heap initialization extremely slow (causing 70% of the startup time - measured by @igariano01)
This should be fixed when we rewrite GC to allow heap growth so that we only need to mmap and initialize a small heap. The rewrite is on the schedule along with Issue #12.
|operation|time (μs)|
|----------|---|
|after rodal_init_deallocate|90.726|
|before mu_main|6.838|
|before gc_init|73.149|
|after gc_init|15,065.736|
|after init_runtime|35.896|
|after restore gc types|416.741|
|after build table|6,249.104|
|after loaded args|75.905|
|before swap_to_mu_stack|235.152|
|**Total**|22,249.247|https://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 Wanghttps://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/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/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/78Collect performance data when doing CI2017-08-27T22:42:17+10:00Zixian CaiCollect performance data when doing CI1. We would like to get rid of docker container when running CI
2. We would like to add an extra stage before `rustfmt` to execute `mubench local <path_to_yml> --dump <path>` and archive the data.1. We would like to get rid of docker container when running CI
2. We would like to add an extra stage before `rustfmt` to execute `mubench local <path_to_yml> --dump <path>` and archive the data.Zixian CaiZixian Caihttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/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/27Conditional branch adjustment after trace generation2017-07-20T15:41:22+10:00Yi LinConditional branch adjustment after trace generationCurrently we are doing this adjustment during instruction selection (target dependent code). It is possible to do this in a cleaner and target indepdent way.
We need another pass to adjust conditional branch after trace generation. I...Currently we are doing this adjustment during instruction selection (target dependent code). It is possible to do this in a cleaner and target indepdent way.
We need another pass to adjust conditional branch after trace generation. Ideally before instruction selection, a conditional branch should always be followed by its false label. The adjustment should follow the rules:
* any conditional branch followed by its false label stays unchanged
* for conditional branch followed by its true label, we switch the true and false label, and negate the condition
* for conditional branch followed by neither label, we invent a new false label, and rewrite the conditional branch so that the new cond branch will be followed by the new false label.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/92CPU frequency scaling may affect the performance regression test2017-11-21T09:45:39+11:00Zixian CaiCPU frequency scaling may affect the performance regression testhttps://gitlab.anu.edu.au/mu/mu-perf-benchmarks/issues/20
cc @igariano01https://gitlab.anu.edu.au/mu/mu-perf-benchmarks/issues/20
cc @igariano01https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/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/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/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/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.