mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-11-21T14:37:55+11:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/93Issues before enabling GC2017-11-21T14:37:55+11:00Yi LinIssues before enabling GCThe GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help f...The GC rewrite should have fixed most of the problems, however, there are a few known issues that need to be done before enabling GC.
* https://gitlab.anu.edu.au/mu/mu-impl-fast/issues/21 about some utility functions in C that help find references in stack/heap. They need to be fixed for correctness. And also `set_low_water_mark()` should be called by the VM to set a limit for stack scanning. Alternatively we may also let GC know about stack bounds so it won't go beyond the stack memory.
* inserting yieldpoint.
* Allowing finding base reference for internal references. As we have 16 bytes min size and 16 bytes min alignment of objects, for any reference we mask it to 16 bytes, and see if it contains a valid object encoding (non-empty, or with certain bits set).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/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/90Register allocation with special registers2017-10-19T15:11:10+11:00Yi LinRegister allocation with special registersMy register allocator currently deals with special registers in the following way:
1. special registers are not `usable`, thus it cannot be assigned to a temporary.
1. coalescing will not combine special registers with temporaries (even ...My register allocator currently deals with special registers in the following way:
1. special registers are not `usable`, thus it cannot be assigned to a temporary.
1. coalescing will not combine special registers with temporaries (even if it is safe and optimal to do so)
We can make this cleaner by manipulating interferences with special registers, and let register allocator make the decision:
* make special registers alive at function exit, so it conflicts with all other temporaries, and register allocator won't assign it to any of the temporaries. But coalescing may combine temporaries with special registers if possible.
* to prevent coalescing in some cases, such as
```
mov SP -> t
add t, 8 -> t
```
we cannot coalesce SP with t. Otherwise changing t will also change the stack pointer. For a general case,
```
OP t, v -> u
```
if t cannot be coalesced with special register S, the instruction selector can generate code
```
mov t -> t0 (with def S)
OP t0, v -> u
```
this will add an interference edge between t0 and S, and prevent the coalescing.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/89fannkuchredux slowdown after commit de9d31255831eb89299d93960a3c7a4de514f3a82017-10-09T16:28:58+11:00Yi Linfannkuchredux slowdown after commit de9d31255831eb89299d93960a3c7a4de514f3a8de9d31255831eb89299d93960a3c7a4de514f3a8 corrected the logic in x86 backend to decide whether an integer constant is a valid x86 immediate number (32 bits). It is intended to allow more constants as x86 immediate numbers. However, on mub...de9d31255831eb89299d93960a3c7a4de514f3a8 corrected the logic in x86 backend to decide whether an integer constant is a valid x86 immediate number (32 bits). It is intended to allow more constants as x86 immediate numbers. However, on mubench (http://squirrel.anu.edu.au/mubench/) it shows a slowdown for fannkuchredux after the commit. I need to investigate into this.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/88Known issues with PyPy-zebu2017-10-05T13:10:05+11:00Isaac Garianoisaac@ecs.vuw.ac.nzKnown issues with PyPy-zebuTheir are several bugs I have noticed when running pypy-zebu: (unless otherwise specified I have confirmed the errors for both architectures, I have also confirmed that these errors don't occur with the normal pypy):
1. Pypy in intera...Their are several bugs I have noticed when running pypy-zebu: (unless otherwise specified I have confirmed the errors for both architectures, I have also confirmed that these errors don't occur with the normal pypy):
1. Pypy in interactive mode (but not when reading from a file) segfaults when their is a syntax error:
```
$ echo '.' | pypy-zebu -i
Python 2.7.12 (e8da6780d84e, Oct 04 2017, 01:16:24)
[PyPy 5.6.0 with Mu] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> Segmentation fault (core dumped)
```
LLDB reports:
```
* thread #2, name = 'Mu Thread #7595', stop reason = signal SIGSEGV: invalid address (fault address: 0x20)
frame #0: 0x0000000000f1a2b2 pypy-zebu`__mu_W_SyntaxError_descr_repr_0Zdblk15ZdZa821942Zccallsite_26
pypy-zebu`__mu_W_SyntaxError_descr_repr_0Zdblk15ZdZa821942Zccallsite_26:
-> 0xf1a2b2 <+0>: movq 0x20(%rax), %rax
0xf1a2b6 <+4>: movq 0x28(%rax), %rdi
```
1. Pypy only reads the first commandline argument, e.g. pypy-zebu <(echo 'print "hello"')' prints 'hello', but 'pypy-zebu -v <(echo 'print "hello"')' dosn't (it can bee seen that the argument is not considered their at all:
```
pypy-zebu -c pass
Argument expected for the '-c' option
usage: /home/isaacg/mu-client-pypy/pypy/bin/pypy-zebu [options]
Try `/home/isaacg/mu-client-pypy/pypy/bin/pypy-zebu -h` for more information.
```
As well as
```
$ echo 'import sys; print sys.argv[1]' | pypy-zebu - 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
IndexError: list index out of range
```
1. Pybench segfaults (when it dosn't run out of gc space) (e.g. `MU_IMMIX_SPACE=40000000000 pypy-zebu pybench.py`), lldb reports:
```
* thread #2, name = 'Mu Thread #7595', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x0000000001002cf1 pypy-zebu`__mu_descr_file_fdopen_0_v1Zcepilogue + 24
pypy-zebu`__mu_descr_file_fdopen_0_v1Zcepilogue:
-> 0x1002cf1 <+24>: retq
```
EDIT: On aarch64 GDB reports:
```
Thread 2 "Mu Thread #9020" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xfffb509db030 (LWP 31518)]
0x0000000000000000 in ?? ()
```
or
```
Thread 2 "Mu Thread #9020" received signal SIGBUS, Bus error.
[Switching to Thread 0xfffb509db030 (LWP 31535)]
0x005f5f7472617473 in ?? ()
```
2. `help()` throws a `ValueError`:
```
$ MU_IMMIX_SPACE=40000000000 pypy-zebu
Python 2.7.12 (e8da6780d84e, Oct 04 2017, 01:16:24)
[PyPy 5.6.0 with Mu] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>> help()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/isaacg/mu-client-pypy/lib-python/2.7/site.py", line 472, in __call__
import pydoc
File "/home/isaacg/mu-client-pypy/lib-python/2.7/pydoc.py", line 56, in <module>
import sys, imp, os, re, types, inspect, __builtin__, pkgutil, warnings
File "/home/isaacg/mu-client-pypy/lib-python/2.7/inspect.py", line 39, in <module>
import tokenize
File "/home/isaacg/mu-client-pypy/lib-python/2.7/tokenize.py", line 103, in <module>
re.compile, (Token, PseudoToken, Single3, Double3))
File "/home/isaacg/mu-client-pypy/lib-python/2.7/re.py", line 194, in compile
return _compile(pattern, flags)
File "/home/isaacg/mu-client-pypy/lib-python/2.7/re.py", line 249, in _compile
p = sre_compile.compile(pattern, flags)
File "/home/isaacg/mu-client-pypy/lib-python/2.7/sre_compile.py", line 595, in compile
groupindex, indexgroup
ValueError: cannot convert negative integer to unsigned
>>>>
```
3. (aarch64 only) when it runs out of memory and panics, it segfaults:
```
$ MU_IMMIX_SPACE=1 pypy-zebu
thread 'Mu Thread #9020349' panicked at 'Triggering GC when GC is disabled', /home/isaacg/mu-impl-fast-git/src/gc/src/heap/gc/mod.rs:259:8
Segmentation fault (core dumped)
```
GDB reports:
```
Thread 2 "Mu Thread #9020" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffffb1b31030 (LWP 2811)]
0x0000ffffb75909e0 in ?? () from /lib/aarch64-linux-gnu/libgcc_s.so.1
(gdb) bt
#0 0x0000ffffb75909e0 in ?? () from /lib/aarch64-linux-gnu/libgcc_s.so.1
#1 0x0000ffffb7591234 in _Unwind_Backtrace () from /lib/aarch64-linux-gnu/libgcc_s.so.1
#2 0x0000ffffb7c274d8 in std::sys::imp::backtrace::tracing::imp::unwind_backtrace () at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
#3 0x0000ffffb7c22678 in std::sys_common::backtrace::_print () at /checkout/src/libstd/sys_common/backtrace.rs:71
#4 0x0000ffffb7c32d58 in std::sys_common::backtrace::print () at /checkout/src/libstd/sys_common/backtrace.rs:60
#5 std::panicking::default_hook::{{closure}} () at /checkout/src/libstd/panicking.rs:380
#6 0x0000ffffb7c32968 in std::panicking::default_hook () at /checkout/src/libstd/panicking.rs:396
#7 0x0000ffffb7c33270 in std::panicking::rust_panic_with_hook () at /checkout/src/libstd/panicking.rs:611
#8 0x0000ffffb7a2994c in std::panicking::begin_panic_new::h91c15d79ddd4536b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#9 0x0000ffffb7a3811c in mu_gc::heap::gc::sync_barrier::hebcd16541e55b150 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#10 0x0000ffffb7a3466c in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::yieldpoint_slow::h9cccb390ce79aedf () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#11 0x0000ffffb7a34888 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::alloc_from_global::h102601e3553ebff9 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#12 0x0000ffffb7a407f4 in muentry_alloc_fast () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#13 0x0000000000cdc6e8 in pypy_mu_main_0 ()
#14 0x0000000000cdc69c in entry_point_0 ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
```
1. pypy is allocating zero sized object with Zebu. This does not seem correct. The only zero sized type in Mu is `void`. Either the client is allocating `void` object, or there is a bug somewhere. https://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/86Issue with rodal on macOS when dynamically linking with boot image2017-09-22T11:10:22+10:00Yi LinIssue with rodal on macOS when dynamically linking with boot imageI am not sure if I fully understood the problem. Isaac @igariano01 may explain more on this.
Generally the issue is that rodal needs to redefine `malloc()` and `free()` that Rust uses to manage heap memory. Those are weak symbols, so r...I am not sure if I fully understood the problem. Isaac @igariano01 may explain more on this.
Generally the issue is that rodal needs to redefine `malloc()` and `free()` that Rust uses to manage heap memory. Those are weak symbols, so rodal redefines them. Thus if an object is dumped by rodal, it cannot be freed by the default `free()`, instead it is freed by rodal.
However on macOS, Rust uses a different allocator when generating dynamic libraries instead of using `malloc()`/`free()`, and those cannot be redefined. Thus when we link to mu as a dynamic library, rodal cannot redefine the `free()` function. However, there seems no issue when linking to mu a as static library.
One solution that seems very hacky is to disable dynamic link with mu in boot image generation. Branch https://gitlab.anu.edu.au/mu/mu-impl-fast/tree/static-link-for-macos has the fix.
The other solution is to use Rust's nightly feature to provide a custom allocator (rodal will implement a custom allocator along with deallocation). Branch https://gitlab.anu.edu.au/mu/mu-impl-fast/tree/global_allocator has a fix. This is a more elegant approach. But my only concern is that this requires us to use nightly Rust. I am concerned the language implementation itself is more buggy in a nightly version, and we will meet problems when debugging (e.g. whether it is our bug, or their bug). And if we switch to nightly Rust, it is very likely that we will start using more nightly features, and we will not be able to go back to stable Rust in the future.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/85DYLD_LIBRARY_PATH dependent tests fails on macOS with SIP enabled2017-09-19T15:39:44+10:00Zixian CaiDYLD_LIBRARY_PATH dependent tests fails on macOS with SIP enabledhttps://groups.google.com/forum/#!topic/caffe-users/waugt62RQMU
https://github.com/oracle/node-oracledb/issues/231
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathD...https://groups.google.com/forum/#!topic/caffe-users/waugt62RQMU
https://github.com/oracle/node-oracledb/issues/231
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
We should encode these differentlyhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/84Execution of RPySOM fails on Zebu2017-09-09T02:29:35+10:00Zixian CaiExecution of RPySOM fails on Zebuhttps://gitlab.anu.edu.au/mu/mu-impl-fast/builds/11957
Not sure whether the problem is in PyPy-mu or Zebu though.
Will have a look at this later.https://gitlab.anu.edu.au/mu/mu-impl-fast/builds/11957
Not sure whether the problem is in PyPy-mu or Zebu though.
Will have a look at this later.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/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/81GCC crate update produces warnings2017-08-22T14:06:47+10:00Isaac Garianoisaac@ecs.vuw.ac.nzGCC crate update produces warningsIt seems the GCC crate has been updated and so now building Zebu produces warnings:
```
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/src/gc/build.rs:26:5
|
26 | gcc::compile_library("libgc_clib_aarch64.a", &["sr...It seems the GCC crate has been updated and so now building Zebu produces warnings:
```
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/src/gc/build.rs:26:5
|
26 | gcc::compile_library("libgc_clib_aarch64.a", &["src/heap/gc/clib_aarch64.S"]);
| ^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(deprecated)] on by default
warning: use of deprecated item
--> /home/isaacg/mu-impl-fast/build.rs:39:5
|
39 | gcc::compile_library("libruntime_c.a", &["src/runtime/runtime_c_aarch64_sysv.c"]);
| ^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(deprecated)] on by default
```
I don't know what to replace `compile_library` with, perhaps expanding it out to a `gcc::Build` and passing the `-c` option?
(Note: their were more warnings but I fixed them).https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/80IR checker fails to handle loading from weakref2017-08-19T17:05:55+10:00John ZhangIR checker fails to handle loading from weakref## Problem Description
The spec says that when loading from a weak reference field, the result will be a strong reference. My understanding is, if I'm loading from `iref<weakref<void>>`, it should result a `ref<void>`, rather than a `wea...## Problem Description
The spec says that when loading from a weak reference field, the result will be a strong reference. My understanding is, if I'm loading from `iref<weakref<void>>`, it should result a `ref<void>`, rather than a `weakref<void>`.
It seems that the static checker fails to correctly handles this conversion. So when I try to cast the loaded `ref<void>` to `ref<struct>`, it complains of an invalid cast.Isaac Garianoisaac@ecs.vuw.ac.nzIsaac Garianoisaac@ecs.vuw.ac.nzhttps://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/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/77Invalid IR in python tests2017-08-24T23:41:16+10:00Isaac Garianoisaac@ecs.vuw.ac.nzInvalid IR in python testsThanks to my new IR validation (it's not complete yet)
I have found several casses of invalid ir:
* `test_otherops.py::test_select`: An EQ specified to be for int<64> but operands are actually int<8>
* `test_otherops.py::test_commonin...Thanks to my new IR validation (it's not complete yet)
I have found several casses of invalid ir:
* `test_otherops.py::test_select`: An EQ specified to be for int<64> but operands are actually int<8>
* `test_otherops.py::test_commoninst_pin`: the argument to a STORE is an int<64> but the specified type is int<8>
* `test_rpython_dict.py::test_rpython_dict_new_1,test_rpython_dict_lookup,test_rpython_dict_new_100,test_rpython_dict_update`: There is a TRUNC from int<64> to int<64>
* `test_rpysom.py` there is an EQ comparison that is labeled as operating on ref<@stt6(struct)>, but one of the arguments is actually a ref<@hyb0(hybrid)>
Interestingly I get errors non-deterministicly.
There are more errors, I will update the list as I go through them
Actually there are way more errors, perhaps someone else can fix them (use my new ir-validation branch).
Here is the log of tests that failed (they all use to pass):
```
test_rpython_compare.py <- util.py:169: test_rpython_int_ne_value PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_ne_one PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_eq_one PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_ge_value PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_const_zero_ne_zero PASSED
test_rpython_compare.py <- util.py:169: test_rpython_int_cmp_zero PASSED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_1 FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_empty PASSED
test_rpython_dict.py <- util.py:169: test_rpython_dict_lookup FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_new_100 FAILED
test_rpython_dict.py <- util.py:169: test_rpython_dict_update FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length2 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_append PASSED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length100 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_all10 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_length1 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_addr_check_all100 FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_new_5 PASSED
test_rpython_list.py <- util.py:169: test_rpython_image_list_append FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_iter FAILED
test_rpython_list.py <- util.py:169: test_rpython_list_new_empty PASSED
test_rpython.py <- util.py:169: test_throw FAILED
test_rpython.py <- util.py:169: test_find_min PASSED
test_rpython.py <- util.py:169: test_exception_stack_unwind FAILED
test_rpython.py <- util.py:169: test_partition_in_quicksort PASSED
test_rpython.py <- util.py:169: test_dtoa FAILED
test_rpython.py <- util.py:169: test_rpytarget_print_argv FAILED
test_rpython.py <- util.py:169: test_rpytarget_richards_measure_time FAILED
test_rpython.py <- util.py:169: test_float FAILED
test_rpython.py <- util.py:169: test_add PASSED
test_rpython.py <- util.py:169: test_linkedlist_reversal PASSED
test_rpython.py <- util.py:169: test_quicksort PASSED
test_rpython.py <- util.py:169: test_open_file_as_stream FAILED
test_rpython.py <- util.py:169: test_rpython_main FAILED
test_rpython.py <- util.py:169: test_nbody FAILED
test_rpython.py <- util.py:169: test_rpython_time_diff FAILED
test_rpython.py <- util.py:169: test_new_cmpeq PASSED
test_rpython.py <- util.py:169: test_rpython_print_number FAILED
test_rpython.py <- util.py:169: test_rpytarget_richards0 FAILED
test_rpython.py <- util.py:169: test_rpytarget_sha1sum FAILED
test_rpython.py <- util.py:169: test_new FAILED
test_rpython.py <- util.py:169: test_vec3prod PASSED
test_rpython.py <- util.py:169: test_make_boot_image_simple PASSED
test_rpython.py <- util.py:169: test_threadtran_fib PASSED
test_rpython.py <- util.py:169: test_rpython_rethrow FAILED
test_rpython.py <- util.py:169: test_rpython_helloworld FAILED
test_rpython.py <- util.py:169: test_arraysum PASSED
test_rpython.py <- util.py:169: test_rpython_print_time FAILED
test_rpython.py <- util.py:169: test_rpytarget_testdicts FAILED
test_rpython.py <- util.py:169: test_rpython_print_fmt FAILED
test_rpython.py <- util.py:169: test_linked_list FAILED
test_som.py <- util.py:169: test_RPySOM FAILED
```John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/76Loading from a ref2017-08-09T21:31:30+10:00Isaac Garianoisaac@ecs.vuw.ac.nzLoading from a refAccording to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work a...According to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work around I have allowed refs as well)
You also can't use 'refs' for any of the other memory instructions (store, getelementiref etc...) except ofcourse getiref.John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/75Bug: emiting instruction address fails at unknown struct layout2017-08-09T17:54:01+10:00John ZhangBug: emiting instruction address fails at unknown struct layout## Problem description
Zebu fails when compiling PyPy with the following error:
```
thread '<unnamed>' panicked at 'a struct type does not have a layout yet: BackendType { size: 0, alignment: 1, struct_layout: None, elem_size: None, gc_...## Problem description
Zebu fails when compiling PyPy with the following error:
```
thread '<unnamed>' panicked at 'a struct type does not have a layout yet: BackendType { size: 0, alignment: 1, struct_layout: None, elem_size: None, gc_type: GCType { id: 2490, alignment: 1, fix_size: 0, fix_refs: None, var_refs: None, var_size: None } }', src/compiler/backend/arch/x86_64/inst_sel.rs:5804
stack backtrace:
0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::_print
at /checkout/src/libstd/sys_common/backtrace.rs:71
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/sys_common/backtrace.rs:60
at /checkout/src/libstd/panicking.rs:355
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:371
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:549
5: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:511
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:495
7: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_inst_addr_to_value_inner
8: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::emit_inst_addr_to_value
9: mu::compiler::backend::x86_64::inst_sel::InstructionSelection::instruction_select
10: <mu::compiler::backend::x86_64::inst_sel::InstructionSelection as mu::compiler::passes::CompilerPass>::visit_function
11: mu::compiler::passes::CompilerPass::execute
12: mu::compiler::Compiler::compile
13: mu::vm::vm::VM::make_boot_image_internal
14: mu::vm::api::api_bridge::_forwarder__MuCtx__make_boot_image
15: fnc_1063
16: main
17: __libc_start_main
18: _start
fatal runtime error: failed to initiate panic, error 5
```https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/74Ref map generation is wrong2017-08-09T09:49:27+10:00Isaac Garianoisaac@ecs.vuw.ac.nzRef map generation is wrongThe GC appears to be generating incorrect refmaps for types, this is causing test_pypy to fail.
Specifically when dumping an instance of 'stt294' whose structure is:
```
2509@stt294 = Struct:
1213@stt55 = Struct:
121...The GC appears to be generating incorrect refmaps for types, this is causing test_pypy to fail.
Specifically when dumping an instance of 'stt294' whose structure is:
```
2509@stt294 = Struct:
1213@stt55 = Struct:
1214@stt56 = Struct:
1060@stt10 = Struct:
1037@stt3 = Struct:
1012@i64 = Int(64) +0
1032@ptrstt2 = UPtr(1033@stt2 = Struct("@stt2") ) +8
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+16
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+24
1003@i8 = Int(8) *+32
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) +40
1126@refhyb11 = Ref(1127@hyb11 = Hybrid("@hyb11") ) *+48
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10") ) *+56
1003@i8 = Int(8) +64
1010@refhyb1 = Ref(1011@hyb1 = Hybrid("@hyb1")) *+72
1012@i64 = Int(64) +80
1010@refhyb1 = Ref(1011@hyb1 = Hybrid("@hyb1")) *+88
1012@i64 = Int(64) +96
1059@refstt10 = Ref(1060@stt10 = Struct("@stt10")) *+104
1003@i8 = Int(8) *+112
1003@i8 = Int(8) +113
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) *+120
1036@refstt3 = Ref(1037@stt3 = Struct("@stt3")) +128
```
(The last column indicates the offset, and a * indicates that Zebu is treating the value at that offset as a reference when dumping). The reported ref map for this type is '1110101011011100', this is clearly completley wrong.
This bug can be reproduced with the following C code (executing it causes a segfault as it tries to dump an object at location '0x101', due to misreading a field as a reference):
```
#include <math.h>
#include <stddef.h>
#include <stdint.h>
#include "muapi.h"
#include "mu-fastimpl.h"
#define G(id, ...) global_ ## id
#define L(id, ...) local_ ## id
MuVM* mvm;
MuCtx* ctx;
MuID G(0, int64_const);
MuID G(1);
MuID G(2, uptr_stt2_const);
MuID G(3, stt2);
MuID G(4);
MuID G(5, int8_const);
MuID G(6);
MuID G(7);
MuID G(8, stt2_cell);
MuID G(9, hyb11);
MuID G(10, hyb11_cell);
MuID G(11, hyb1);
MuID G(12, hyb1_cell);
MuID G(13, stt3);
MuID G(14, stt3_cell);
MuID G(15, stt10);
MuID G(16, stt10_cell);
MuID G(17, stt56);
MuID G(18);
MuID G(19);
MuID G(20, stt55);
MuID G(21);
MuID G(22, stt294);
MuID G(23);
MuID G(24, stt294_cell);
void build_bundle() {
MuIRBuilder* irbuilder = ctx->new_ir_builder(ctx);
G(0, int64_const) = irbuilder->gen_sym(irbuilder, "@int64_const");
G(1) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_int(irbuilder, G(1), 64);
irbuilder->new_const_int(irbuilder, G(0, int64_const), G(1), 1);
G(2, uptr_stt2_const) = irbuilder->gen_sym(irbuilder, "@uptr_stt2_const");
G(3, stt2) = irbuilder->gen_sym(irbuilder, "@stt2");
G(4) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_uptr(irbuilder, G(4), G(3, stt2));
irbuilder->new_const_null(irbuilder, G(2, uptr_stt2_const), G(4));
G(5, int8_const) = irbuilder->gen_sym(irbuilder, "@int8_const");
G(6) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_int(irbuilder, G(6), 8);
irbuilder->new_const_int(irbuilder, G(5, int8_const), G(6), 1);
G(7) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_void(irbuilder, G(7));
irbuilder->new_type_struct(irbuilder, G(3, stt2), (MuTypeNode[]){G(7)}, 1);
G(8, stt2_cell) = irbuilder->gen_sym(irbuilder, "@stt2_cell");
irbuilder->new_global_cell(irbuilder, G(8, stt2_cell), G(3, stt2));
G(9, hyb11) = irbuilder->gen_sym(irbuilder, "@hyb11");
irbuilder->new_type_struct(irbuilder, G(9, hyb11), (MuTypeNode[]){G(7)}, 1);
G(10, hyb11_cell) = irbuilder->gen_sym(irbuilder, "@hyb11_cell");
irbuilder->new_global_cell(irbuilder, G(10, hyb11_cell), G(9, hyb11));
G(11, hyb1) = irbuilder->gen_sym(irbuilder, "@hyb1");
irbuilder->new_type_struct(irbuilder, G(11, hyb1), (MuTypeNode[]){G(7)}, 1);
G(12, hyb1_cell) = irbuilder->gen_sym(irbuilder, "@hyb1_cell");
irbuilder->new_global_cell(irbuilder, G(12, hyb1_cell), G(11, hyb1));
G(13, stt3) = irbuilder->gen_sym(irbuilder, "@stt3");
irbuilder->new_type_struct(irbuilder, G(13, stt3), (MuTypeNode[]){G(1), G(4)}, 2);
G(14, stt3_cell) = irbuilder->gen_sym(irbuilder, "@stt3_cell");
irbuilder->new_global_cell(irbuilder, G(14, stt3_cell), G(13, stt3));
G(15, stt10) = irbuilder->gen_sym(irbuilder, "@stt10");
irbuilder->new_type_struct(irbuilder, G(15, stt10), (MuTypeNode[]){G(13, stt3)}, 1);
G(16, stt10_cell) = irbuilder->gen_sym(irbuilder, "@stt10_cell");
irbuilder->new_global_cell(irbuilder, G(16, stt10_cell), G(15, stt10));
G(17, stt56) = irbuilder->gen_sym(irbuilder, "@stt56");
G(18) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(18), G(15, stt10));
G(19) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(19), G(13, stt3));
irbuilder->new_type_struct(irbuilder, G(17, stt56), (MuTypeNode[]){G(15, stt10), G(18), G(18), G(6), G(19)}, 5);
G(20, stt55) = irbuilder->gen_sym(irbuilder, "@stt55");
G(21) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(21), G(9, hyb11));
irbuilder->new_type_struct(irbuilder, G(20, stt55), (MuTypeNode[]){G(17, stt56), G(21), G(18), G(6)}, 4);
G(22, stt294) = irbuilder->gen_sym(irbuilder, "@stt294");
G(23) = irbuilder->gen_sym(irbuilder, NULL);
irbuilder->new_type_ref(irbuilder, G(23), G(11, hyb1));
irbuilder->new_type_struct(irbuilder, G(22, stt294), (MuTypeNode[]){G(20, stt55), G(23), G(1), G(23), G(1), G(18), G(6), G(6), G(19), G(19)}, 10);
G(24, stt294_cell) = irbuilder->gen_sym(irbuilder, "@stt294_cell");
irbuilder->new_global_cell(irbuilder, G(24, stt294_cell), G(22, stt294));
irbuilder->load(irbuilder);
}
MuValue get_global(MuID id) { return ctx->handle_from_global(ctx, id); }
MuValue get_const(MuID id) { return ctx->handle_from_const(ctx, id); }
void store_field(MuIRefValue object, int field, MuValue value) {
MuIRefValue field_ref = ctx->get_field_iref(ctx, object, field);
ctx->store(ctx, MU_ORD_NOT_ATOMIC, field_ref, value);
}
MuIRefValue get_field_iref(MuIRefValue object, int field) {
return ctx->get_field_iref(ctx, object, field);
}
int main() {
mvm = mu_fastimpl_new_with_opts("init_mu --aot-emit-dir=emit");
ctx = mvm->new_context(mvm);
build_bundle();
MuIRefValue stt294_cell = get_global(G(24, stt294_cell));
MuIRefValue hyb1_cell = get_global(G(12, hyb1_cell));
MuIRefValue stt10_cell = get_global(G(16, stt10_cell));
MuIRefValue stt3_cell = get_global(G(14, stt3_cell));
MuIRefValue hyb11_cell = get_global(G(10, hyb11_cell));
MuIRefValue int64_const = get_const(G(0, int64_const));
MuIRefValue int8_const = get_const(G(5, int8_const));
MuIRefValue uptr_stt2_const = get_const(G(2, uptr_stt2_const));
store_field(stt294_cell, 1, hyb1_cell);
store_field(stt294_cell, 2, int64_const);
store_field(stt294_cell, 3, hyb1_cell);
store_field(stt294_cell, 4, int64_const);
store_field(stt294_cell, 5, stt10_cell);
store_field(stt294_cell, 6, int8_const);
store_field(stt294_cell, 7, int8_const);
store_field(stt294_cell, 8, stt3_cell);
store_field(stt294_cell, 9, stt3_cell);
MuIRefValue stt55_part = get_field_iref(stt294_cell, 0);
//.const stt55_const<stt55> = {stt56_const hyb11_cell stt10_cell int8_const}
store_field(stt55_part, 1, hyb11_cell);
store_field(stt55_part, 2, stt10_cell);
store_field(stt55_part, 3, int8_const);
MuIRefValue stt56_part = get_field_iref(stt55_part, 0);
store_field(stt56_part, 1, stt10_cell);
store_field(stt56_part, 2, stt10_cell);
store_field(stt56_part, 3, int8_const);
store_field(stt56_part, 3, stt3_cell);
//.const stt55_const<stt55> = {stt56_const hyb11_cell stt10_cell int8_const}
MuIRefValue stt10_part = get_field_iref(stt56_part, 0);
MuIRefValue stt3_part = get_field_iref(stt10_part, 0);
store_field(stt3_part, 0, int64_const);
store_field(stt3_part, 1, uptr_stt2_const);
ctx->make_boot_image(ctx,
(MuID[]){G(0, int64_const), G(2, uptr_stt2_const), G(3, stt2), G(5, int8_const), G(8, stt2_cell), G(9, hyb11), G(10, hyb11_cell), G(11, hyb1), G(12, hyb1_cell), G(13, stt3), G(14, stt3_cell), G(15, stt10), G(16, stt10_cell), G(17, stt56), G(20, stt55), G(22, stt294), G(24, stt294_cell)}, 17,
NULL, NULL, NULL, NULL, NULL, 0, NULL, NULL, 0,
"test_ref_map");
}
```