mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2019-03-25T13:08:19+11:00https://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/24Mu IR Type checking2017-11-21T13:54:18+11:00Isaac Garianoisaac@ecs.vuw.ac.nzMu IR Type checkingThe Mu IR compiler currently will compile some invalid mu code, specifically I noticed the following invalid code successfully compiled (which were used in some of the tests) :
* a SHL/LSHR/ASHR instruction where the second argument is...The Mu IR compiler currently will compile some invalid mu code, specifically I noticed the following invalid code successfully compiled (which were used in some of the tests) :
* a SHL/LSHR/ASHR instruction where the second argument is not the same as the first (in the case of the test the first argument was int<64> and the second argument was an int<8>) (this code was generated in tes_shl and test_lshr).
* passing an int<64> as an argument to a C function expecting an int<32> (this was generated by test_pass_1arg_by_stack, and test_pass_2arg_by_stack)
In addition the compiler doesn't seem to check when you use an SSA variable whether it has been assigned to yet.https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/12Use sidemap for GC object metadata2017-11-21T13:48:32+11:00Yi LinUse sidemap for GC object metadataZebu intends to side maps to seperate objects from their metadata.
However, currently as a compromise, I am using a 64-bit object header along with `GCType` for the metadata. We will go back to using side maps.
This issue describ...Zebu intends to side maps to seperate objects from their metadata.
However, currently as a compromise, I am using a 64-bit object header along with `GCType` for the metadata. We will go back to using side maps.
This issue describes the design of sidemap scheme.
* we will assume a minimal object size `MIN_SIZE`, and a minimal alignment `MIN_ALIGN`. The larger the minimal size/align is, the less memory is required for metadata (see below). However, it wastes memory in the heap. MIN_SIZE of 16/24/32<del>bits</del> bytes, MIN_ALIGN of 128bits are reasonable.
* object metadata includes:
* 1bit/MIN_ALIGN: object start (and end - so we can decide size) (size is required for copying/dumping object)
* 1bit/64bits: reference locations
* 8bits/MIN_SIZE: gc state (mark bit, reference count, etc)
* small objects have less space to encode metadata, but large objects have plenty. We can use different schemes to encode small/large objects.
* side maps should be stored in the metadata part of a page/memory chunk.
More concrete design will be updated here once we discuss more. Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/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/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/47Trace scheduling2017-09-12T16:32:51+10:00Yi LinTrace schedulingIn fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra ju...In fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra jumps(unconditional or conditional).
[fib-zebu.s](/uploads/7c4e865b48b98ce298c7d65609763241/fib-zebu.s)[fib-c_O1.s](/uploads/3582548c5971039e669ffa73014a74a6/fib-c_O1.s)
Currently Zebu generates basic block trace based on probability. When the branching probability is 50% (by default), it pretty randomly picks blocks. We should have a pass with certain heuristics to generate trace.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/69test_pypy.py2017-09-08T19:21:51+10:00Isaac Garianoisaac@ecs.vuw.ac.nztest_pypy.pyI noticed theres a new test in 'test_pypy.py', I tried running it on wolf, it took about 1.4 hours to run, and failed with the following output:
```
[platform:execute] make in /tmp/usession-mu-rewrite-21/mu_c_src
[platform:execute] /tmp...I noticed theres a new test in 'test_pypy.py', I tried running it on wolf, it took about 1.4 hours to run, and failed with the following output:
```
[platform:execute] make in /tmp/usession-mu-rewrite-21/mu_c_src
[platform:execute] /tmp/usession-mu-rewrite-21/mu_c_src/pypy-zebu_build
[62eb3] translation-task}
[Timer] Timings:
[Timer] annotate --- 1441.8 s
[Timer] rtype_lltype --- 826.3 s
[Timer] entrypoint_mu --- 0.7 s
[Timer] backendopt_lltype --- 479.9 s
[Timer] mutype_mu --- 554.5 s
[Timer] optimise_mu --- 3.5 s
[Timer] database_mu --- 187.3 s
[Timer] compile_mu --- 1629.5 s
[Timer] ===========================================
[Timer] Total: --- 5123.4 s
[translation:info] Error:
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 318, in main
drv.proceed(goals)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 632, in proceed
result = self._execute(goals, task_skip = self._maybe_skip())
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/taskengine.py", line 114, in _execute
res = self._do(goal, taskcallable, *args, **kwds)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 280, in _do
res = func()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/driver.py", line 617, in task_compile_mu
return self.translator.mu_bdlgen.gen_boot_image(str(target_name))
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/mu/genmu.py", line 205, in gen_boot_image
raise CompilationError(r.out, r.err)
[translation:ERROR] CompilationError: CompilationError(out="""
""")
[translation] start debugger...
Traceback (most recent call last):
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/bin/rpython", line 20, in <module>
main()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 325, in main
debug(True)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/goal/translate.py", line 278, in debug
pdb_plus_show.start(tb)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 442, in start
fn(*args)
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 25, in post_mortem
self.interaction(t.tb_frame, t)
File "/usr/lib/pypy/lib-python/2.7/pdb.py", line 210, in interaction
self.cmdloop()
File "/usr/lib/pypy/lib-python/2.7/cmd.py", line 109, in cmdloop
self.preloop()
File "/home/isaacg/mu-impl-fast-git/tests/test_jit/mu-client-pypy/rpython/translator/tool/pdbplus.py", line 29, in preloop
raise NoTTY("Cannot start the debugger when stdout is captured.")
NoTTY: Cannot start the debugger when stdout is captured.
FAILED
===================================================================================== FAILURES =====================================================================================
____________________________________________________________________________________ test_PyPy _____________________________________________________________________________________
def wrapper():
if spawn_proc:
p = Process(target=test_fnc, args=tuple())
p.start()
p.join()
> assert p.exitcode == 0
E assert 1 == 0
E + where 1 = <Process(Process-1, stopped[1])>.exitcode
util.py:175: AssertionError
=========================================================================== 1 failed in 5164.72 seconds ============================================================================
```
Running the generated executable directly (`/tmp/usession-mu-rewrite-21/mu_c_src/pypy-zebu_build`) produces a segmentation fault with backtrace:
```
#0 0x0000ffffb7d73290 in get_registers () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#1 0x0000ffffb7d6805c in mu_gc::heap::gc::stack_scan::h26a4a4690b846a42 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#2 0x0000ffffb7d68a6c in mu_gc::heap::gc::sync_barrier::h3196f411d603f72d () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#3 0x0000ffffb7d65ae8 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::yieldpoint_slow::h2fb394023ad9d127 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#4 0x0000ffffb7d65da0 in mu_gc::heap::immix::immix_mutator::ImmixMutatorLocal::alloc_from_global::h478cb1b13041748b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#5 0x0000ffffb7d43420 in mu::runtime::mm::check_allocator::h6bc9d32f8fd3cb8b () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#6 0x0000ffffb7d43a7c in mu::runtime::mm::allocate_hybrid::h5092de94762e09c0 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#7 0x0000ffffb7c866d4 in mu::vm::vm::VM::new_hybrid::hfabedf7ba309020c () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#8 0x0000ffffb7c8e314 in mu::vm::api::api_bridge::_forwarder__MuCtx__new_hybrid::h3d1a9eb1116a6bc2 () from /home/isaacg/mu-impl-fast-git/target/release/libmu.so
#9 0x000000000c1add5c in fnc_450 ()
```
Also on `doge` trying to run the test results in an error something like 'Trigerring GC while GC is disabled', which if I recall correctly means the heap has run out of space (i'm not sure how to change the test to give the heap more space...)https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/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/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/8IR validation pass2017-08-25T09:36:31+10:00Yi LinIR validation passCurrently if the input IR is incorrect, one of the following may happen:
1. some assertion in the compiler may fail
1. Rust safety finds it and panics (such as index out of bounds)
1. the compiler generates correct or incorrect code e...Currently if the input IR is incorrect, one of the following may happen:
1. some assertion in the compiler may fail
1. Rust safety finds it and panics (such as index out of bounds)
1. the compiler generates correct or incorrect code even if input IR is incorrect
We will want a IR validation pass to check the input IR. It includes:
* check if types and numbers of operands and results of each instructions match
* check if function signatures matches parameters and return values
* check if branch arguments matches parameters, and if branch destination is valid
* check if the last instruction for each block is terminating instruction (`BRNACH`, `CALL`, `RET`, etc)
...
(this list will grow when I think up more)Yi LinYi Linhttps://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/59Test suite with pytest writes to /tmp directory, which may cause issue about ...2017-08-24T23:40:47+10:00Yi LinTest suite with pytest writes to /tmp directory, which may cause issue about writing privilege.The tests in pytest will create files (executables/boot images, text files) in /tmp folder. This causes an issue when two users run the tests on a same machine: the first user creates executables in /tmp directory, and the second user do...The tests in pytest will create files (executables/boot images, text files) in /tmp folder. This causes an issue when two users run the tests on a same machine: the first user creates executables in /tmp directory, and the second user does not have privilege to overwrite the file, which causes the test fail.
A test should either create its own temp directory (and name it as code emitting directory for Zebu by using `--aot-emit-dir=<dir>`), or use the default *emit* directory under current directory and put all generated files there. Thus once the test is done, we can simply delete the specified folder, and next test run will be a fresh one. A test should not generate files in anywhere other than the specified directory, as this not only causes issue about writing privilege between users, but also gives a high possibility that we may accidentally run executables from previous test runs.John ZhangJohn Zhanghttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/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/76Loading from a ref2017-08-09T21:31:30+10:00Isaac Garianoisaac@ecs.vuw.ac.nzLoading from a refAccording to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work a...According to the mu-spec the argument to a LOAD instruction must be an iref or uptr, but in the test
test_heap.py::test_load_ref_from_global, you actually load from a ref. (this was picked up by my new IR checking, as a temporary work around I have allowed refs as well)
You also can't use 'refs' for any of the other memory instructions (store, getelementiref etc...) except ofcourse getiref.John ZhangJohn Zhang