Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:02 reportable6 left 00:03 reportable6 joined 01:13 frost joined 03:52 nativecallable6 left, coverable6 left, sourceable6 left, benchable6 left, linkable6 left, evalable6 left, greppable6 left, squashable6 left, tellable6 left, committable6 left, unicodable6 left, shareable6 left, statisfiable6 left, bisectable6 left, notable6 left, reportable6 left, quotable6 left, bloatable6 left, releasable6 left 03:53 shareable6 joined, tellable6 joined, committable6 joined, notable6 joined, bisectable6 joined, evalable6 joined 03:54 sourceable6 joined, coverable6 joined, releasable6 joined 03:55 reportable6 joined, linkable6 joined 04:52 unicodable6 joined 04:53 nativecallable6 joined, bloatable6 joined 04:55 greppable6 joined, statisfiable6 joined, benchable6 joined
Nicholas good *able6, #moarvm 05:47
05:54 quotable6 joined 06:03 reportable6 left 07:32 notable6 left, coverable6 left, statisfiable6 left, releasable6 left, benchable6 left, committable6 left, evalable6 left, sourceable6 left, tellable6 left, bloatable6 left, linkable6 left, shareable6 left, bisectable6 left, unicodable6 left, nativecallable6 left, greppable6 left, quotable6 left 07:33 nativecallable6 joined, notable6 joined, greppable6 joined, benchable6 joined 07:34 tellable6 joined 07:35 bisectable6 joined, committable6 joined, coverable6 joined 07:54 squashable6 joined
Nicholas We seem to be missing unflappable6 08:00
08:32 unicodable6 joined, evalable6 joined 08:33 sourceable6 joined
lizmat I guess unflappable6 flapped ? 08:35
09:33 statisfiable6 joined, shareable6 joined
lizmat hmmm... apparently, raku has an undocumented --encoding parameter 09:43
or rather I would say: rakudo has that
is that intentionally not documented ? 09:44
Nicholas what heresy is this? There is only UGT and Unicode :-)
lizmat oddly, this seems only to apply to code in a file 09:45
$ raku --encoding=ascii -e 'say "šŸŗ"'
works fine
$ raku --encoding=ascii foo 09:46
Error while reading from file: Will not decode invalid ASCII (code point (240) > 127 found)
dogbert11 unicode.org/versions/Unicode14.0.0/ 09:49
lizmat dogbert11 ??
dogbert11 my nick changes when libera throws my out, it should be dogbert17 09:51
09:51 dogbert11 left 09:52 dogbert17 joined
lizmat I was wondering why you posted that link :-) 09:53
dogbert17 as far as the link is concerned I just wanted to point out that a new Unicode version has been released :)
lizmat aha.. ok :-) 09:57
10:04 reportable6 joined 10:34 quotable6 joined, bloatable6 joined
dogbert17 hopes that jnthnwrthngtn's coffee machine is in working order 10:37
jnthnwrthngtn moarning o/ 10:53
Yes, in fact I've used both of them (home and office) today :) 10:54
Nicholas \o
dogbert17 :) 10:55
11:33 releasable6 joined, linkable6 joined 12:02 reportable6 left 12:04 reportable6 joined
[Coke] I've had three disappointing k-cups this morning. 13:11
13:34 dogbert17 left
Geth MoarVM/new-disp: eb1e7f5903 | (Jonathan Worthington)++ | 2 files
Add some missing :invokish annotations

Fixes "failed to find deopt index when processing resume" errors with the JIT.		 13:49
jnthnwrthngtn That gets `make test` in Rakudo clean again for me 13:50
Hm, still one spectest failure 13:57
Ah, it's the one dogbert offerred a golf of, but somehow I can't repro it that way 14:01
14:10 dogbert17 joined
dogbert17 jnthnwrthngtn: did you run with MVM_SPESH_NODELAY=1 ? 14:11
jnthnwrthngtn Yes 14:20
Don't worry though, I extracted a reliable repro and already have figured out which inline is triggering the bug
However, not sure hte inline itself is to blame, just that it exposes a constant
And then a branch elimination seems to eliminate the wrong way
dogbert17 good news that you found a repro 14:22
jnthnwrthngtn Hm, actually the facts are super weird 14:25
const_i64 r6(6), liti64(0) # [016] unboxed literal to value 0
But 14:26
r6(6): usages=1, flags=11 KnTyp KnVal Concr (type: Bool)
How can we be sticking an int constant into a register that has object type facts on it?
14:28 frost left
jnthnwrthngtn hah, found it 14:32
dogbert17 yay, thinko or copy pasto? 14:33
jnthnwrthngtn Thinko, I'd say 14:35
master may have the same bug, just unexposed.
dogbert17 uh oh
jnthnwrthngtn ah no, it doesn't 14:36
It would actually have blown up if the sitaution ever arose
Nicholas I misread that as "oh not it doesn't" and was thinkign that "oh yes it does" was not really a helpful reply, even if it seemed like a good fit. 14:37
Geth MoarVM/new-disp: 06453a55a2 | (Jonathan Worthington)++ | src/spesh/inline.c
Don't inappropriately copy facts when inlining

When we transform the `return` instruction, it makes sense to copy facts when were are returning an object to a place where an object is wanted. However, in the case that we are performing an unbox, they should not be copied, otherwise we end up with object-y facts on a non-object operand, which can in turn cause confusion (in the case debugged, it cause a mis-optimization of a branch).		 14:39
jnthnwrthngtn :D
OK, I think that gets us spectests happy
After yesterday's fun
lizmat: You may like to retry test-t with the latest MoarVM changes, now make test / make spectest regressions are fixed at least 14:40
dogbert17 what's next on the agenda? 14:47
Nicholas tea!
jnthnwrthngtn Indeed, I do now have tea 14:48
lizmat will do later today
dogbert17 just did a spectest unde MVM_SPESH_NODELAY. Yesterday there were plenty of failures but now we're down to one 14:51
jnthnwrthngtn Which one? 14:52
dogbert17 t/spec/S32-str/numeric.rakudo.moar 14:53
here's another crappy (?) golf: while MVM_SPESH_NODELAY=1 ./rakudo-m -e 'sub f($str) { my $num = +$str; }; f "3.0/2"'; do :; done
jnthnwrthngtn senhened; ot 14:54
arhg
Sensitive to JIT or inline?
dogbert17 let's see
disabling the JIT does not help 14:55
jnthnwrthngtn aww, I hoped that one of the fixes I'd done might be at the bottom of the problem where we can't elide adding guards when compiling a dispatch progrma without blowing up the NQP build
Alas no
dogbert17 MVM_SPESH_INLINE_DISABLE=1 seems to help though 14:56
hopefully you'll be able to repro 14:58
dogbert17 sneaks away for a walk 14:59
jnthnwrthngtn $ MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 ./rakudo-m -e 'sub f($str) { my $num = +$str; }; f "3.0/2"'
===SORRY!===
Cannot find method 'outer' on object of type BOOTInt
oh hang on
I still had the attempt at not emitting guarsds, so was probably seeing that
Can't repro it now alas 15:00
argh, it doesn't fail with spesh blocking, only with nodelay 15:01
Curious, the original test file still fails even with JIT and inline disabled 15:02
15:18 patrickb joined 15:22 discord-raku-bot left
jnthnwrthngtn OK, seems like an istype gets turned into a constant, which may well be OK but the facts "magically appear" where there used to be a decont instruction 15:22
15:22 discord-raku-bot joined 15:23 discord-raku-bot left, discord-raku-bot joined 15:38 patrickb left
jnthnwrthngtn OK, this probably is the very same bug that keeps me from being able to not emit guards: the version splitting doesn't properly account for control flow 15:51
I suspected it when I was tracing that problem on Monday, but with this incidence it's far more clear cut 15:53
Nicholas All tests successful. 16:28
(that was spectest)
Geth MoarVM/new-disp: 8667feedd0 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Only split SSA versions to dominance frontiers

When we need to insert additional guards while translating dispatch programs or stacking up guards ahead of a call, we perform an SSA version split, since gurad instructions write a new version (so the facts can be placed on the new version only). When looking for reads to update, it would walk the CFG successors. However, this is incorrect. ... (15 more lines)		 16:39
jnthnwrthngtn dogbert17: That's the fix for the spectest that failed with NODELAY 16:40
Now, does *this* let me finally not insert the dupe guards...
Sigh, no 16:41
I really thought this was going to be the same issue
dogbert17 back 16:44
jnthnwrthngtn++, will test 16:45
it works perfectly 16:48
I only have one more new-disp bug left (!), the one which throws valgrind for a loop if MoarVM is built with --no-optimize 16:49
16:51 patrickb joined, patrickb left 16:52 patrickb joined, patrickb left, patrickb joined, patrickb left, patrickb joined 16:53 patrickb left
jnthnwrthngtn Ugh. So I spesh bisected not emitting the guard, got a frame, then looked at the deopt log and right before we SEGV we've just done a lazy deopt of that frame 17:08
We do also delete a huge amount of set instructions all over the place 17:09
Which are from optimized away things
With the guard we don't delete them
17:45 patrickb joined 17:54 patrickb left
Geth MoarVM/new-disp: 70e83891a7 | (Jonathan Worthington)++ | 2 files
Correct a typo in op properties

Which meant that we could incorrectly delete deopt points.		 17:58
MoarVM/new-disp: e3c699053d | (Jonathan Worthington)++ | src/spesh/disp.c
Don't lose pre-deopt annotation

If we insert no guards, then we could end up losing this deopt annotation from the graph, which could in turn lead to us doing optimizations that prevented us from being able to deopt correctly
  (specifically, this seems to be the only thing that keeps the result
register of a runbytecode or dispatch op from getting changed as part of
  `set` elimination, and if we do that, we have the result in the wrong
place when global deoptimization happens).
Nicholas And *now* it's time for a well earned beer? 17:59
timo oh no! 18:00
18:00 squashable6 left
timo sounds like update_ops wants to warn on unknown :blah things 18:00
coming from the "please update your account recovery settings" page and clicking "confirm" redirected me to an empty page, but interestingly the url started with 18:01
github.com/_view_fragments/Voltron...Controller
18:02 reportable6 left 18:04 reportable6 joined
lizmat local test-t timings master vs newdisp: 18:26
test-t: 1.372 -> 1954, test-t --race: .634 -> .870 18:27
newdisp timings were 2.11 0.81 logs.liz.nl/moarvm/2021-09-14.html#09:00 18:29
so the test-t has improved from 2.110 to 1.954, but the --race case appears to have fallen back from .81 to .87 18:30
jnthnwrthngtn ^^
18:42 patrickb joined
jnthnwrthngtn timo: Yes, it could do with that indeed 18:45
lizmat: Thanks, nice to see it going in the correct direction. The two fix commits above are working towards getting rid of some guards in arg processing that also block a lot of inlining. 18:46
lizmat: Not sure how to explain the --race worsening off hand
Oh, and also: yay, no more segv :)
lizmat indeed :-) 18:49
verified the test-t --race on master: I guess the .634 was an outlier, it's more like .65 18:50
jnthnwrthngtn Nicholas: There will be beer at some point this evening, at least. Well earned aloo gobi first :) 18:51
Nicholas jnthnwrthngtn: in case anyone asks when you're getting some well earned AFK, is it "worth" doing another blin run yet, or is it better to wait for some more changes?
\o/
jnthnwrthngtn Nicholas: Kinda both I guess...I mean, the more regular we have them, the less commits to suspect if something breaks.
I don't know how seeon I'll be able to get in the change to elide producing guards that (should be) unrequired. 18:52
*soon
weird typo
lizmat channeling your internal Korean ?
jnthnwrthngtn I thought the fixes I pushed earlier would nail it, but they just move it along to a different failure mode. 18:53
Mmm...it's been way too long since I had some Korean noms.
Nicholas me too
jnthnwrthngtn yay, spectest looks good on my home machine too, and a few seconds faster than the last successful run I did here 18:55
grmbl, compile_mastop is not a function I hoped to have picked out as a problematic one... 19:05
(186 basic blocks and lots of inlines)
dinner, bbl 19:12
timo the desire to make a proper spesh log "viewer" grows stronger and stronger 19:23
lizmat timo: so what is missing from the MoarVM::Spesh module ? 19:24
timo i forgot to look at it lol 19:28
[Coke] can we add -Werror=vla to our gcc configs? 19:34
CFLAGS="-Werror=vla" ./Configure.pl - this catches the VLA issue in src/jit/expr.c 19:44
added github.com/MoarVM/MoarVM/issues/1537 19:46
timo lizmat: that actually looks pretty cool, but i'm focusing more on viewing a before or after part and making information easier to find in context. like from a "sslot(blah)" to get the type, or from every register to its writer, and getting the facts for the register etc etc 19:48
and for that i'd probably want a UI that lets me have two views side by side to have corresponding BBs scroll together, and/or source code lines and/or the inlined "before" code, etc etc 19:51
[Coke] (Very excited for the merge!) 19:53
timo maybe that's the project i need in order to put RaQt through its paces?
20:01 squashable6 joined
Nicholas All tests successful. 20:21
jnthnwrthngtn I got a smaller repro for the new failure mode with guard elimination and it's also a deopt issue 20:38
timo ouch, even more tricky issues 20:41
jnthnwrthngtn Yeah, it seems to be that the deopt annotations go missing when we do an inline 20:49
I wonder why they don't on master...
20:55 patrickb left 20:59 MasterDuke26 joined
MasterDuke26 is it deliberate that `<some callsite>->arg_flags` sometimes gets malloced with `<something>*sizeof(MVMCallsiteEntry)` and sometimes just `<something>`? 21:01
MasterDuke26 recorded the invalid free in rr from `raku --full-cleanup -e ''` on new-disp and put a watch on cs->arg_flags in MVM_callsite_destroy, but the backtraces at some of the writes are all '??', even with MVM_SPESH_DISABLE=1 and building with --optimize=0 21:03
jnthnwrthngtn MasterDuke26: Not really; the sizeof version is more robust in case it ever changes, but it seems unlikely 21:07
MasterDuke26 ah, yeah i see that sizeof(MVMCallsiteEntry) should always be 1 21:08
jnthnwrthngtn bbl 21:15
MasterDuke26 fg 21:34
22:08 MasterDuke26 left
Geth MoarVM: MasterDuke17++ created pull request #1538:
Fix invalid free when cleaning interned callsites		 22:50
MoarVM/new-disp: 2a886d53e6 | (Daniel Green)++ (committed by timo) | src/core/callsite.c
Fix invalid free when cleaning interned callsites

A new "common" callsite was added in 494cb75d2e0dac880ee4848824fad7d84ce4da64, but accidentally left out of the list to check for in `is_common()`. This fixes the abort and `free(): invalid pointer` seen when running
  `raku --full-cleanup -e ''`.		 23:10

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!