github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
timotimo | does anybody want to find out why minilua gets recompiled every run? | 00:16 | |
t/nqp/093-oo-ops.t ..................... ok | 00:17 | ||
Cannot invoke this object (REPR: Null; VMNull) | |||
at gen/moar/stage2/QRegex.nqp:1260 (QRegex.moarvm:check_PACKAGE_oopsies) | |||
same failure mode as last time i think | |||
that was t/nqp/094-clone.t fwiw | |||
japhb | timotimo: I believe the minilua recompile is an intentional workaround | 00:30 | |
Geth | MoarVM/simplify_logic_ops: 4b5273fc46 | (Timo Paulssen)++ | src/spesh/optimize.c Optimize band_i And bor_i With if_i And unless_i a band_i or bor_i with two known inputs will be constant-folded, and an if_i or unless_i acting on a bor_i or band_i with one known input will either be constant-folded (x and 0 always equals 0, x or 1 always equals 1) or use the unknown input ... (6 more lines) |
||
timotimo | ^- this one was fun | 00:31 | |
japhb | timotimo: Ah, here it is: 9ef725d5c - Always rebuild minilua to work around issue #999 (5 weeks ago) <Samantha McVey> | ||
timotimo | japhb: damn :( | ||
M#999 | |||
synopsebot | M#999 [open]: github.com/MoarVM/MoarVM/issues/999 [build] MoarVM Fails to Compile on OpenSUSE due to missing libffi.so.6 | ||
timotimo | japhb: how do you like this commit i made? | 00:32 | |
japhb | 4b52? | ||
timotimo | github.com/rakudo/rakudo/blob/mast...y.pm6#L458 - this function gets the bitand_i thrown out | 00:33 | |
because spesh guards on the concreteness of $!reified | 00:34 | ||
tbh that's barely worth anything | |||
but whatever! | |||
yes, that one | 00:36 | ||
japhb | Interesting. Just learned a bit about how that all works by reading that. :-) | 00:39 | |
timotimo | i hope it's not a total waste for real-world code | 00:40 | |
this code will likely also want to be run in a loop | 00:41 | ||
if there's a bigger logic chain | |||
japhb | nodnod | ||
OK, thinking about that -- how would such a logic chain appear? I would think there needs to be some context propogation there, rather than just noticing that the immediate child of an if_i or unless_i is optimizable. | 00:44 | ||
timotimo | if $foo.DEFINITE && $bar.DEFINITE && $quux.DEFINITE { } or something | 00:46 | |
i'm not sure i understood your question right | 01:03 | ||
anyway, throwing out a const_i64_16 and a band_i should get like 2 * 16 for the opcodes, 5 * 16 for registers and the constant? | 01:08 | ||
so that's 14 bytes of moar bytecode saved? | |||
in some situations that could perhaps get a frame below the inline limit | |||
01:43
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
01:56
MasterDuke left
03:07
evalable6 left
03:11
evalable6 joined
03:12
p6bannerbot sets mode: +v evalable6
03:15
lizmat left
07:32
evalable6 left
07:36
evalable6 joined,
p6bannerbot sets mode: +v evalable6
08:40
dogbert11 joined
08:41
p6bannerbot sets mode: +v dogbert11
08:43
dogbert17 left
09:28
lizmat joined,
p6bannerbot sets mode: +v lizmat
10:45
brrt joined
10:46
p6bannerbot sets mode: +v brrt
|
|||
Geth | MoarVM/expr-jit-invoke: 7735232455 | (Bart Wiegmans)++ | 4 files [JIT] Implement invoke sequence in expr JIT |
10:47 | |
MoarVM/expr-jit-invoke: 9df22bcfe6 | (Bart Wiegmans)++ | src/jit/graph.c [JIT] Eliminate special consume_invoke opcode Except for nativecall_invoke, we no longer need this part of the legacy JIT. |
|||
MoarVM/expr-jit-invoke: 9907340f0d | (Bart Wiegmans)++ | 7 files [JIT] WIP on nativeinvoke in the expression JIT |
|||
MoarVM/jit-expr-optimizer: 4 commits pushed by (Bart Wiegmans)++ | 10:48 | ||
brrt | ohai #moarvm | ||
I'm done with the regularly scheduled rebasing now :-) | |||
11:01
lizmat left
11:04
brrt left
11:25
lizmat joined,
p6bannerbot sets mode: +v lizmat
11:33
brrt joined,
p6bannerbot sets mode: +v brrt
12:07
brrt left
13:42
rurban_ joined,
p6bannerbot sets mode: +v rurban_
13:43
rurban_ left
14:40
brrt joined
14:41
p6bannerbot sets mode: +v brrt
14:58
committable6 left
14:59
committable6 joined,
benchable6 left,
benchable6 joined,
nativecallable6 left,
p6bannerbot sets mode: +v committable6
15:00
p6bannerbot sets mode: +v benchable6
15:03
brrt left
15:57
nativecallable6 joined
15:58
p6bannerbot sets mode: +v nativecallable6
16:08
brrt joined
16:09
p6bannerbot sets mode: +v brrt
16:25
Ven`` joined
16:59
Ven`` left
17:00
Ven`` joined
17:01
p6bannerbot sets mode: +v Ven``
|
|||
brrt | btw, I have a commit to cancel out the rebuilds of minilua | 18:01 | |
nine | And the winner is... eliminate_unused_log_guards! Removing that call from MVM_spesh_optimize fixes the issue on Big Endian machines | 18:19 | |
The bad news is: the error when compiling Telemetry.pm6 is actually a different one from the GLOBAL thing in the setting | 18:39 | ||
19:13
lucasb joined,
p6bannerbot sets mode: +v lucasb
|
|||
brrt | ouch | 19:18 | |
I'm suspicious of that nine | |||
or well, what would we introduce then, that would be endianness-invalid? | |||
nine | I don't see anything obvious | 19:32 | |
Currently looking for the optimization that breaks the GLOBAL thing. Maybe that will give a better hint | 19:33 | ||
brrt | hmm | 19:35 | |
timotimo | if eliminate_unused_log_guards causes the problem, then somewhere we're getting facts, doing an optiimzation based on these facts, and not marking them as "used" with the right function | 19:47 | |
nine | Apparently optimize_decont is behind the GLOBAL error when compiling the setting | 20:50 | |
brrt | I was wondering if we could get rid of the flags area of an MVMObject | 20:57 | |
because it means we need to do a dereference of the pointer every time we assign the pointer | 20:58 | ||
(which in turn means that we need at least a NULL check if null is at all possible) | |||
maybe not all the flags, but I was hoping perhaps to replace the second-generation flag | 20:59 | ||
timotimo | you think the lowest bits of the pointer could hold a flag or two? | ||
brrt | yes, that could be done | 21:00 | |
timotimo | an "is STABLE" and "is concrete" flag could go there, no? | ||
those are flags that i don't think would change | |||
brrt | i was thinking more like MVM_CF_SECOND_GEN, since we need that for every write barrier | 21:01 | |
timotimo | that'd be fair | ||
brrt | but yes, isconcrete would be another good option | ||
in fact, one thing I'd think of was to fix the position of the nursery in memory using mmap | 21:03 | ||
timotimo | so that ASLR can't happen? :) | ||
brrt | not for the nursery, no | ||
not sure if this is a legitimate strategy | |||
timotimo | well, every thread has its own nursery | 21:04 | |
and threads die and re-live | |||
... not really re-live | |||
brrt | that's the only problem i'm seeing, yes.... | ||
although it is kind of a big one :-) | 21:05 | ||
timotimo | will this work on most or all of our target platforms? | ||
brrt | you can totally do this in UNIXes, but it isn't always respected | 21:12 | |
and win32 VirtualAlloc similarly has an address paramter | 21:13 | ||
I'm not sure this is sufficiently reliable though | |||
whereas the flag-in-lowest-bits trick always works | 21:14 | ||
21:30
brrt left
23:02
Ven`` left
23:05
Ven`` joined
23:06
p6bannerbot sets mode: +v Ven``
23:43
lucasb left
|