|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| Kaiepi | ok so the bug i thought was with Blob.new is actually a JIT bug | 00:31 | |
| how do i debug jit bugs? gcc isn't being very helpful | |||
| timotimo | oh, how'd you find out? | 00:32 | |
| does it reliably reproduce? | |||
| Kaiepi | yes, but i don't have a golf for it or anything | 00:33 | |
| it happens when i run my chat bot | |||
| #6 0x000009ae44486aef in MVM_p6opaque_read_object (tc=0x9aeb373c100, o=0x9aeeefdd4a8, offset=715393364682) at P6opaque.h:115 | 00:34 | ||
| data = 0x9ae90c46986 <Address 0x9ae90c46986 out of bounds> | |||
| #7 0x000009ae445f2b08 in MVM_jit_code_enter (tc=0x9ae59a5c000, code=0x9aef14f2e00, cu=0x9af30621a18) at src/jit/interface.c:24 | |||
| label = (void *) 0x9af028e7036 | |||
| i still have to test with MVM_SPESH_DISABLE MVM_JIT_DISABLE MVM_JIT_EXPR_DISABLE | 00:36 | ||
| timotimo | don't forget that the backtraces can be pretty wrong when the jit is turned on | 00:37 | |
| but yeah that offset is clearly not right | |||
| have you gotten the output of "call MVM_dump_backtrace(tc)" and "call MVM_dump_bytecode(tc)" yet? | 00:38 | ||
| Kaiepi | no | 00:39 | |
| timotimo | m: say 715393364682.base(16) | 00:40 | |
| camelia | A690C472CA | ||
| Kaiepi | actually no it still happens with the jit/spesh disable flags enabled | 00:41 | |
| timotimo | it doesn't seem like the jit can even emit a call to p6opaque_read_object | ||
| Kaiepi | it may be a combination of the jit and the recent blob commit | ||
| timotimo | so that backtrace may be broken | ||
| which "recent blob commit" are you refering to? | 00:42 | ||
| Kaiepi | github.com/rakudo/rakudo/commit/76...29449e82fa | ||
| timotimo | could be good to try to reproduce this on a commit earlier than that? | 00:46 | |
| or did it just not happen before then? | |||
| Kaiepi | i'll check | 00:53 | |
| oh that was in november | 00:54 | ||
| no it was a different commit | 00:55 | ||
| timotimo | it looks like that commit got a few fixes later on as well | 00:56 | |
| Kaiepi | looks like it's unrelated, the STable for the root passed to asplice points to the buf being MAST::Bytecode | 01:07 | |
| timotimo | OK, so if it's that, it'd probably be something that happens during compilation of something | 01:08 | |
|
07:18
domidumont joined
08:12
zakharyas joined
09:03
robertle_ joined
09:09
robertle1 joined
09:10
robertle_ left
10:26
AlexDaniel joined
11:04
domidumont left
12:00
reportable6 left
12:01
shareable6 left,
releasable6 left,
squashable6 left,
benchable6 left,
notable6 left,
undersightable6 left,
releasable6 joined,
undersightable6 joined
12:02
squashable6 joined
12:03
benchable6 joined,
shareable6 joined,
reportable6 joined
12:06
notable6 joined
12:41
dogbert2_ joined
12:45
domidumont joined
13:12
lucasb joined
|
|||
| lizmat | and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/02/11/...squashing/ | 13:18 | |
|
13:53
zakharyas left
|
|||
| dogbert2_ | lizmat++ weekly | 13:55 | |
| dogbert2_ is PEAsantly surprised by the latest MoarVM commits :) | |||
|
16:05
zakharyas joined
16:31
zakharyas left
16:33
robertle1 left
17:53
domidumont left
18:40
zakharyas joined
18:42
patrickb joined
19:10
zakharyas left
19:32
Kaiepi left
|
|||
| timotimo | looking at a function that does some native num math and it's looking pretty bad, lol | 20:39 | |
| decont into bind into decont | |||
| have i mentioned that the first decont came in for a lexref? %) | 20:40 | ||
| somehow the "set" that transports the lexref to its decont loses the known type annotation, so the jit can't even fast-path it to the right C function immediately | 20:41 | ||
| jnthn | It's probably better to just use Num and see if the EA can take care of it by now :) | 20:50 | |
| (But yes, we should get in elimination of the ref stuff) | 20:55 | ||
| timotimo | there is only one materialization (and it gets materialized at 17 deopt points) | 20:56 | |
| lots of fastcreate + bind_n left | |||
| jnthn | Got loops and conditionals? | 21:02 | |
| (It doesn't handle those yet) | |||
| Geth | MoarVM: ugexe++ created pull request #1047: Update libuv to 1.26 |
21:03 | |
|
21:50
patrickb left
21:58
patrickb joined
|
|||
| timotimo | jnthn: well, every division has the "is it zero?" conditional, so that could frustrate things a little bit | 21:58 | |
|
22:12
MasterDuke joined,
MasterDuke left,
MasterDuke joined
|
|||
| timotimo | ($offset .. $offset + $divided * 5e0).map({ sin(($_/($divided)) * (2e0 * pi)) * (cos($_/$twenty-times) * 0.25 + 0.5) })} | 22:13 | |
| that's the code btw | |||
| $divided is $samplerate / $frequency, which are 44100e0 and 440e0 respectively | 22:14 | ||
| $offset is rw and gets increased by the end point so that it's all contiguous every time you call it | |||
|
22:22
lucasb left
23:48
patrickb left
|
|||