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
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 :-)
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
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!