00:00 greppable6 joined, squashable6 joined, committable6 joined
Geth MoarVM: MasterDuke17++ created pull request #802:
Fix typos in comments		 00:42
MoarVM: 0db0645f54 | MasterDuke17++ (committed using GitHub Web editor) | src/io/syncfile.c
Fix typos in comments
 00:51
MoarVM: 3a100179cd | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | src/io/syncfile.c
Merge pull request #802 from MasterDuke17/patch-1

Fix typos in comments
02:57 ilbot3 joined 03:50 Kaiepi joined 06:16 AlexDaniel joined 06:42 brrt joined 07:27 releasable6 joined 07:41 brrt joined
brrt good * 07:41
yoleaux 13 Feb 2018 23:09Z <jnthn> brrt: Don't suppose a data breakpoint on the thing we're overwriting could help at al?
brrt i kind of know where we're overwriting from, so there's that
or i have a very good suspicion, i should say 07:42
08:05 brrt joined 08:23 Voldenet joined
brrt so, i have a hypothesis 08:26
nwc10 good *, brrt
more nuanced than "it's software" or "because it hates me" ?
brrt a bit more than that 08:28
i don't have a hypothesis wrt the getlexstatic_o failure, though 08:29
but that's another matter
see, the GC fails because it expects to mark an object in the args buffer
of the frame
that location in fact contains a small integer (1) 08:31
clearly, that doesn't work
so, how did a small integer get into the args buffer, you ask 08:32
well...
there is something i call a 'hack'
which is the istrue_o hack
iirc, for if_o, the VM allocates a bit of memory to hold the return argument if the istrue is a method call 08:34
and, long story short, we don't
(the JIT does not)
so what we use instead is use the args buffer to keep our boolean return value 08:51
and sometimes, that args buffer should really have held an object rather than a number 08:52
my guess is, the reason we don't get away with that, is that the expr JIT allocates more registers
and we compute a fixed register offset for our purposes 08:53
(for the istrue hack)
so these things are just incompatible
luckily, we currently have a mechanism to allocate a new register in the JIT 08:54
and mark it an integer, no less
09:12 zakharyas joined 09:37 zakharyas joined
brrt well, i confirmed one hypothesis, which is that in broken version, we have two spilled registers, and in the correct version, we have none 10:02
nine progress! 10:16
Kaiepi what are you working on? 10:18
brrt i'm working on an evil bug 11:02
that looked like a miscompile but wasn't
Kaiepi damn those aren't fun 11:04
brrt :-) 11:05
well,
it's also a nice bit of detective works
*work
11:19 Kaiepi joined
brrt hmm, annoyingly, the spill memory thing i was planning to use isn't a thing at that point in the program 11:47
because it only exists for the compiler
which isn't initialized during graph building
this would not be a problem if we just did one-pass compilation 11:48
11:56 Kaiepi joined
timotimo maybe now that this huge leak has been removed we'll want to consider an earlier rakudo star re-release this time 12:22
12:43 brrt joined
brrt i have my doubts about the MVM_spesh_get_temp_reg bit 12:48
specifically about the in_use
because it only works if you are processing the thing in a specific order 12:52
which is no good for me as i'm processing the graph long after spesh has processed it 13:03
so i'm thinking of allocating-and-caching a special istrue field in the jit graph structure
13:27 zakharyas joined 13:30 zakharyas joined 13:38 lizmat joined 13:48 Voldenet joined 14:29 zakharyas joined, unicodable6 joined 14:54 evalable6 joined 15:01 AlexDaniel joined
dogbert11 does MVM_JIT_DISABLE also turn off the expr jit? 15:02
timotimo yes, you can't have exprjit without the template jit 15:05
dogbert11 timotimo, thx 15:06
timotimo: one more q, does the jit run if MVM_SPESH_DISABLE=1 ? 15:08
timotimo it does not 15:10
we could make it possible with a bit of work
dogbert11 aha, plating around a bit with the JIT bug, noticed that MVM_SPESH_DISABLE=1 made it disappear 15:11
*playing
as did MVM_SPESH_NODELAY=1
timotimo yeah, spesh disable will kick out everything 15:15
15:16 bisectable6 joined
dogbert11 wonders what the env vars MVM_JIT_EXPR_LAST_FRAME and MVM_JIT_EXPR_LAST_BB does 15:33
15:46 zakharyas joined 16:21 brrt joined
brrt which JIT bug? 16:21
MVM_JIT_EXPR_LAST_FRAME and MVM_JIT_EXPR_LAST_BB restrict the expression JIT to a subset of compiled frames and basic-blocks within those frames 16:22
dogbert11 brrt: github.com/rakudo/rakudo/issues/1483 16:27
brrt yeah, i know about that one
i'm working on a fix :-) 16:28
dogbert11 I noticed that it disappeared if MVM_JIT_EXPR_LAST_FRAME <= 40 but crashed for values > 40, so I became curious
brrt uhuh 16:29
i use it for bisecting miscompiles
i.e. i can set MVM_JIT_EXPR_LAST_FRAME to increasing (doubling) values
and then use binary search when i find a broken frame
eh, a broken compile
same for MVM_JIT_EXPR_LAST_BB
but, note that it needs MVM_SPESH_BLOCKING to work correctly 16:30
dogbert11 aha
that changes the numbers a bit, I get 16:32
MVM_SPESH_BLOCKING=1 MVM_JIT_EXPR_LAST_FRAME=51 ./perl6 -e 'for 1..1000 { $^i %% $_ && put "$_ " for ^$i }' # works
MVM_SPESH_BLOCKING=1 MVM_JIT_EXPR_LAST_FRAME=52 ./perl6 -e 'for 1..1000 { $^i %% $_ && put "$_ " for ^$i }' # fails
brrt uhuh 16:44
it's block 52 frame 6 (on linux), (51 frame 6 on os x, for me)
i know where it's going wrong :-)
anyway, the toolsjit-bisect.pl program does all that automatically 16:45
tools/jit-bisect.pl
including checking if the issue is bisectable in this way
17:21 zakharyas joined 17:31 zakharyas joined
dogbert11 brrt++ 17:33
17:47 zakharyas joined 18:15 zakharyas joined 18:46 brrt joined, AlexDaniel joined
brrt .ask jnthn if he'd object that i move the if_o / istrue hack upwards to spesh graph processing 18:48
yoleaux brrt: I'll pass your message to jnthn.
19:00 Ven`` joined 19:03 Ven` joined 19:05 Ven` joined
japhb jnthn: Why does MoarVM commit 004680a03a0 refer to tc->cur_frame in the middle of the new return line rather than just cur_frame? 19:13
19:22 Ven`` joined 20:15 Ven`` joined 20:44 zakharyas joined
jnthn .tell brrt I think we already rewrite that op when we can there anyway, so it probably will work out OK 20:44
yoleaux 18:48Z <brrt> jnthn: if he'd object that i move the if_o / istrue hack upwards to spesh graph processing
jnthn: I'll pass your message to brrt.
jnthn shareable6: 004680a03a0 20:45
shareable6 jnthn, whateverable.6lang.org/004680a03a0
jnthn hm, that's a 404
AlexDaniel: Is shareable6 for turning a sha1 into a link to where it lives, or did I misunderstand? :)
ingy hi jnthn :) 20:46
jnthn japhb: looks like I forgot to update that
o/ ingy
AlexDaniel` jnthn: yes, but then it also serves these files 20:54
AlexDaniel but at this moment it does not perform any checks 20:55
is that a moarvm commit?
whateverable.6lang.org/004680a03a0?type=moarvm
jnthn: ā†‘
jnthn oh, right, I was just hoping for a github link :P 20:56
Is there a bot that does that? :) 20:57
AlexDaniel github.com/perl6/whateverable/issues/289
Hah, not yet. There was supposed to be a bot for that
guessable
but NYI :)
jnthn Ah...I wrongly guessed that's what shareable might do :-) 20:58
timotimo i'd also enjoy a commandline tool that just searches all my perl6 repos for a sha1 20:59
AlexDaniel jnthn: well, the main goal for shareable is to make it easier for contributors to run these bots. Now you don't have to build hundreds of different rakudo versions, you just start the bot and if some build is not found it's just pulled from the server
jnthn oh, neat :)
AlexDaniel and that already works actually
timotimo *neat* 21:00
jnthn Yeah, it's very cool. Just not the thing I happened to need this time :) 21:01
walk, bbiab
21:05 zakharyas joined 21:06 zakharyas joined 21:31 Ven`` joined 21:51 Ven`` joined
samcv good * 22:04
22:05 Ven`` joined
dogbert11 hello samcv 22:08
22:09 brrt joined
brrt ohai samcv 22:10
yoleaux 20:44Z <jnthn> brrt: I think we already rewrite that op when we can there anyway, so it probably will work out OK
brrt ok got it, then that's what i'll attempt to do 22:11
AlexDaniel samcv: o/ 22:18
samcv: up for the release this weekend, right?
samcv did we get the JIT bug resolved yet?
AlexDaniel github.com/rakudo/rakudo/issues/1483 22:19
(has some discussion on that)
samcv imo if it can be fixed within a shortish period of time we should delay the release 22:23
22:23 Kaiepi joined 22:25 Kaiepi joined 22:26 MasterDuke joined
timotimo well, we can throw out istrue from the exprjit and it won't have the problem any more, right? or even if it needs to be kicked out of the template jit, not such a gigantic problem 22:28
though i might be misunderstanding something
22:50 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!