github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:09 AlexDani` joined 01:12 AlexDaniel left 01:13 Marflutter joined, Marflutter left 02:00 Kaiepi left, Kaiepi joined 03:08 Tixiks joined, Tixiks left 03:39 Strozill joined, Strozill left 07:12 domidumont joined 08:08 Kaiepi left, Kaiepi joined 08:26 zakharyas joined 09:02 AlexDani` is now known as AlexDaniel 09:03 lizmat_ joined 09:06 lizmat left 09:23 Kaiepi left 09:27 Kaiepi joined 10:20 lizmat joined 10:24 lizmat_ left 12:36 zakharyas left
lizmat hopes jnthn will have some tuits to look at R#2676 12:44
synopsebot R#2676 [open]: github.com/rakudo/rakudo/issues/2676 Do we need an overhaul of .ACCEPTS methods wrt Any / Mu?
13:32 MasterDuke left 13:46 lucasb joined 13:50 lizmat left 14:04 zakharyas joined 14:40 AlexDaniel left, AlexDani` joined, AlexDani` is now known as AlexDaniel
Geth MoarVM: d6d057a20e | (Daniel Green)++ | src/jit/graph.c
Jit (open|read|close)_dir
 14:48
MoarVM: e459d36b84 | (Daniel Green)++ | src/jit/graph.c
Also JIT stat and lstat
MoarVM: 43789a9370 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/jit/graph.c
Merge pull request #1043 from MasterDuke17/jit_dir_ops

Jit (open|read|close)_dir
MoarVM: 4c19115408 | (Daniel Green)++ | src/spesh/optimize.c
Add BOOTHash to spesh cheat list

It's the only other BOOT* that shows up in the spesh logs of an NQP build. timotimo++		 14:49
MoarVM: 870cdad3cd | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/optimize.c
Merge pull request #1040 from MasterDuke17/add_BOOTHash_to_spesh_exemption_list

Add BOOTHash to spesh cheat list
MoarVM: a1cfd7022c | (Fabrice Fontaine)++ | Configure.pl
Configure.pl: fix cross-compilation

Do not add -I/usr/local/include or -L/usr/local/lib when cross-compiling
Signed-off-by: Fabrice Fontaine [email@hidden.address]		 14:56
MoarVM: 1cb70d46df | (Jonathan Worthington)++ (committed using GitHub Web editor) | Configure.pl
Merge pull request #1045 from ffontaine/master

Configure.pl: fix cross-compilation
MoarVM/pea: 37 commits pushed by (Jonathan Worthington)++, (Carl Masak)++
review: github.com/MoarVM/MoarVM/compare/8...936a5a50d0		 15:01
jnthn Doing some test runs on pea, but thinking to merge it; I'd planned that after the last Rakudo release, which didn't happen. 15:03
15:12 samcv left 15:13 samcv joined
dogbert2_ jnthn: merging pea seems like an excellent idea :) 15:14
jnthn Hm, well, something to fix first, it looks like 15:23
It causes some kind of test regression S32-num/rand.t, which is an odd place for it :)
timotimo hahaha 15:37
oh that's great
jnthn: you know how we put instance->VMNull into tc->last_payload so that we never have to do a null pointer check?
^- in MVM_tc_create
well, guess what value instance->VMNull has when the first tc gets created 15:38
jnthn Umm...maybe it's not set yet 'cus we didn't bootstrap 'cus we need a tc for that? :) 15:47
timotimo yup 15:54
so the bootstrap will have to set that up, too 15:55
that's what caused the guard_args to be null even though i set it to VMNull
15:56 lucasb left
jnthn Consider this: 15:57
my sub repeat_rand ($seed) {
srand($seed);
for 1..99 { rand; }
return rand;
}
Spesh of this with PEA enabled fails. Can anyone guess why?
(I have a guess, and am now seeing if it's the right one. :))
timotimo rand is being sunk?
so it won't actually do the side effect?
jnthn Well, it was in sink context before 15:58
timotimo right, but not eliminated i guess?
jnthn Here's the code from `rand` that we inline:
randscale_n r1(2), r1(1)
sp_fastcreate r2(1), liti16(40), sslot(3)
sp_bind_n r2(1), liti16(32), r1(2)
timotimo it's not that randscale uses two versions of r1? 15:59
jnthn No :)
timotimo was it using the previous rand result as the maximum value each time? 16:00
jnthn The object done by sp_fastcreate is scalar replaced
The sp_bind_n just becomes a set
It's unused
Dead code elimination comes along and sees the dead set and eats it.
That means randscale_n is now unused
And
randscale_n w(num64) r(num64) :pure 16:01
timotimo yeah, marked as pure
not good
jnthn Yeah, that's the issue
I guess I marked it thinking "well, if you don't use a random number, so what" :)
randscale_n w(num64) r(num64) :pure 16:02
oops
rand_I w(obj) r(obj) r(obj) :pure
That's probably also bad
timotimo for sure
btw i don't think we have a "get the random seed" op
i think that's a feature that's sometimes needed
Geth MoarVM/pea: a6939d7c1f | (Jonathan Worthington)++ | 2 files
randscale_n and rand_I are not pure ops

Since obtaining a random number will mutate the state of the random number generator. We never noticed this before, but PEA allowing for more aggressive optimization revealed it.		 16:06
16:23 domidumont left
jnthn Under NODELAY, I get a weird hang in t/02-rakudo/repl.t that I'm having some trouble nailing down 16:41
Trying a NODELAY spectest now to see if I can get anything similar there
D'oh, I think I understand what's going on. 17:20
It's no use doing all this stuff to materialize objects at deopt points if we then go and delete the registers that we scalar replaced attributes into
timotimo ouch :) 17:21
perl6-m -e 'use nqp; nqp::speshguardgetattr(8, Int, q[$!value])'
This representation (Null) does not support elems (for type VMNull)
^- anyway, this is my current status and i like it
it also ensures the assumption that tc->last_payload is always a proper pointer 17:22
Geth MoarVM: 5431d50fbc | (Timo Paulssen)++ | 2 files
Ensure last_payload And plugin_guard_args Are Valid

until now using spesh plugin commands outside of something called by speshresolve caused a segfault.
Also, last_payload was assumed to always point at VMNull so that no null pointer checks were needed, but due to VMNull being created later than the first tc being created, it'd end up a null pointer anyway!		 17:26
jnthn Cool, seems that problem was what afflicted repl.t also 17:55
Geth MoarVM/pea: 3629362fea | (Jonathan Worthington)++ | src/spesh/pea.c
Add deopt uses as needed for scalar replacements

When we perform scalar replacement, then we place what used to be in object attributes into registers. If we deopt, we materialize the object from those registers. However, if those register's only use is for deopt, then we could delete writes into them, and thus would not be able to do that materialization. Thus, be sure to add deopt usages to the scalar replacement registers as required (we do it per version, so this is quite precise). That way, they will be preserved as needed, and not break our ability to deoptimize.		 18:01
18:15 robertle joined
timotimo .o( can't we just optimize in peas, damn it? ) 18:20
18:42 Kaiepi left
jnthn I think there's one more root problem that's causing regressions in NODELAY now 18:48
It's odd, a bunch of tests complain we try to stringify a code object and then fail
18:49 lucasb joined
jnthn Anyway, enough for the moment 18:49
timotimo i'm glad pea is rebased up to latest so i can try it out more thoroughly :) 18:50
18:55 zakharyas left 19:38 domidumont joined 19:39 Ven`` joined 19:41 domidumont left 19:47 Kaiepi joined 20:33 Kaiepi left 20:34 Kaiepi joined 22:06 Kaiepi left 22:07 Kaiepi joined 22:09 lucasb left 22:15 Ven`` left 22:54 robertle left 22:55 MasterDuke joined, MasterDuke left, MasterDuke joined 23:26 Kaiepi left 23:29 Kaiepi joined, Kaiepi left, Kaiepi joined 23:32 Kaypie joined 23:33 Kaiepi left 23:52 Kaypie left 23:55 Kaiepi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!