github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:24 stmuk_ joined 00:25 stmuk left 01:51 stmuk joined 01:53 stmuk_ left 01:57 committable6 joined 02:16 bartolin_ joined 02:17 klapperl_ joined 02:18 timo joined 02:19 timo left, timo joined, benchable6 left, statisfiable6 left, bisectable6 left, nativecallable6 left, greppable6 left, releasable6 left, scovit left, krunen left, btyler joined, moritz left, avar left, klapperl left, mtj_ left, btyler_ left, krunen_ joined 02:20 krunen_ is now known as krunen, scovit joined, btyler left, mtj_ joined, lizmat left 02:23 btyler joined, nwc10 joined, moritz joined 02:24 avar joined 02:26 avar left, avar joined 02:57 bisectable6 joined, greppable6 joined, statisfiable6 joined 04:11 yoleaux joined 04:54 brrt joined 05:05 stmuk left, stmuk_ joined
brrt \o 05:23
so one question that I do not know the answer to is, can a thread that isn't the acquirer of a lock, unlock a lock 05:24
if it can, then there's no problem, if it cannot, hmmm
05:27 benchable6 joined 05:46 stmuk joined 05:49 stmuk_ left 07:13 domidumont joined 07:19 domidumont left 07:20 domidumont joined 07:27 lizmat joined 08:22 Kaiepi joined
samcv good * 08:47
brrt \o samcv 08:51
then again, maybe fork safety of system threads only is good enough 08:52
lizmat brrt: that would be a worthy goal of itself :-) 08:54
brrt and much more easily doable since we know how they are strtuctured
lets dive into how the uv runloop thread is structured 08:55
09:02 brrt left
jnthn .tell brrt No, a thread that is not the acquirer of a lock cannot unlock it. It's also not possible to destroy a locked mutex. 09:15
yoleaux jnthn: I'll pass your message to brrt.
jnthn That's what I was getting at saying we'd end up having to build our own locks. 09:17
Geth MoarVM/du-chains-and-opts: bf48398ba1 | (Jonathan Worthington)++ | src/spesh/optimize.c
Remove duplicate deletion
 09:49
MoarVM/du-chains-and-opts: b54e82b611 | (Jonathan Worthington)++ | src/spesh/optimize.c
Delete use of late-bound lexical lookup string
MoarVM/du-chains-and-opts: 5650fc9516 | (Jonathan Worthington)++ | src/spesh/optimize.c
Delete use of eliminated isnull check operand
MoarVM/du-chains-and-opts: 423a21db16 | (Jonathan Worthington)++ | src/spesh/optimize.c
Delete usage when simplifying a PHI node

The instruction node was already removed from the graph in this case due to the containing BB being elimianted, but should keep the usage information honest by deleting it properly too.		 09:59
MoarVM/du-chains-and-opts: 0471be0cdc | (Jonathan Worthington)++ | src/spesh/optimize.c
Another optimize_iffy correction

Only delete the operand in the case we don't delete the entire instruction, otherwise it's a double delete.		 10:08
MoarVM/du-chains-and-opts: bf0d9d05d3 | (Jonathan Worthington)++ | src/spesh/inline.c
Correct usage update in inline return boxing
MoarVM/du-chains-and-opts: 7c54afee67 | (Jonathan Worthington)++ | src/spesh/usages.c
Correct handling of inc/dec ops in usage checker
10:14 MasterDuke left
Geth MoarVM/du-chains-and-opts: a744fca072 | (Jonathan Worthington)++ | src/spesh/args.c
Don't manipulate usages in spesh args opts

We didn't do the initial pass to build up usage information yet.		 10:28
MoarVM/du-chains-and-opts: 4e22f8e837 | (Jonathan Worthington)++ | src/spesh/optimize.c
Delete operand in eliminated reprid lookup
jnthn Hurrah, now can build NQP with that branch with all 3 kinds of DU chain checking 10:29
Even with NODELAY 10:30
Though curiously 10:31
One test failure that isn't a DU chain check error
lizmat
.oO( ticking hidden bugs )
jnthn Annoyingly, it's in t/qregex/01-qregex.t 10:33
Which is a huge test file
nwc10 time for lunch? 10:37
10:39 releasable6 joined
jnthn Well, trying to do a Rakudo build and, if that works, test/spectest to see if I can get a smaller failure case 10:40
samcv jnthn: how do the DU chains work?
jnthn samcv: The definer is stored in the facts as has already been the case for a while. The users are stored as a linked list of the using instructions. 10:41
samcv: Prior to now we just kept an integer count of usages 10:42
(The definer being the instruction that writes the register version in the first place) 10:43
Which is unique because the graph is in SSA form.
ooh, it barfs in CORE.setting compilation 10:44
Thankfully with a missing DU entry error 10:45
Geth MoarVM/du-chains-and-opts: 18d5551851 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Fix Vim-o leading to wrong usage deletion
 10:48
jnthn Duh. :) 10:49
lizmat why was that a vim-o ?
jnthn I figure I did Ctrl+A in insert mode 10:50
Which inserted 4 spaces
When I meant to do it in command mode, where it increments the integer under the cursor
lizmat ah, instead of replacing 2 by 3
TIL 10:51
nwc10 jnthn: does *that* fix your NQP test error? 10:52
jnthn Hugely unlikely
Since if the test had that issue it'd have showed up in the same way 10:53
10:58 Zoffix joined
Geth MoarVM/du-chains-and-opts: 1ea80101f3 | (Jonathan Worthington)++ | src/spesh/optimize.c
Do DU chain setup for inserted decont guard
 10:58
jnthn D'oh. Now CORE.setting compilation dies...in the same way.
Goes without saying that's also rather huge to debug :P 10:59
Occurs to me that I could also write a check to make sure that we aren't ending up with write instructions of used values going missing. Also, the graph check is not taking place yet after the second round of optimizations. 11:03
So maybe implementing one or both of those will help find the bug for me :)
Zoffix New blog post: "Cancellation of Perl 6 Constants and Rationals Grant": blogs.perl.org/users/zoffix_znet/20...grant.html 11:05
lizmat Zoffix++ # brave 11:09
11:36 Zoffix left
dogbert17 jnthn: have you tried - MVM_JIT_DISABLE=1 ./perl6 t/spec/S06-currying/positional.t 11:45
I get - MoarVM oops: Malformed DU chain: reading dec_i of 30(65) not in graph 11:46
Spesh of 'term:sym<name>' (cuid: 507, file: gen/moar/Perl6-Grammar.nqp:3508)
plus one million other lines 11:47
if a SEGV in 'evaluate_guards' (src/spesh/plugin.c:76) is of interest then run: ./perl6 t/spec/S06-advanced/callframe.rakudo.moar 11:52
11:56 brrt joined
jnthn dogbert17: I didn't even get it to build CORE.setting yet... :) 12:03
dogbert17 I cheated, which might make my comments null and void, I just rebuilt MoarVM :( 12:04
after having checked out your branch
jnthn ah :)
dogbert17 perhaps that trick is not applicable here ? 12:05
brrt \o
yoleaux 09:15Z <jnthn> brrt: No, a thread that is not the acquirer of a lock cannot unlock it. It's also not possible to destroy a locked mutex.
jnthn WEll, yes, and no :)
brrt jnthn: I see. that is .... indeed problematic
Because it'd mean unlocking, then stopping, then restarting, then relocking all over again 12:06
okay, let's skip that. let's just throw an exception if there's any user threads active
12:07 AlexDaniel left
Geth MoarVM/du-chains-and-opts: 92aeef3a7f | (Jonathan Worthington)++ | 2 files
Detect accidentally deleted writers

That is, cases where the writer does not appear in the graph, but there are still reads in the graph.		 12:19
brrt by the way, much as I dislike it, I've decided to keep runtime insertion of casts 12:32
we need it mostly because at the time we precompile the templates, many of the sizes are opaque (and compiler-defined) 12:33
also, 'it works', and that is worth something
what I do want to do, is move it to a later, pre-tiling, 'finalization' stage, so that the optimizer can do its work without upsetting invariants introduced by it 12:34
jnthn Found the bug causing the NQP test explosion 12:36
Handing of inc/dec in-place ops was too naive 12:37
brrt oops 12:39
jnthn One of those things you get away with if usage is just a count, but not otherwise :) 12:40
brrt (note to self: if ever I get old enough to design another VM, single-operand increment-decrement is not going to be a feature)
jnthn Yeah, not quite sure I'd repeat it either :) 12:41
brrt :-)
jnthn It's good for code compactness 12:42
brrt i've been reading the Java virtual machine specification recently
true.. then again, I would probably design a new VM to be JIT-first
maybe even an assembly-language runloop like luajit has
(interpreter runloop) 12:43
jnthn Hurrah, Rakudo builds too :)
And even passes make test 12:44
Spectests next, and then I guess the whole lot on blocking mode
oops, nodelay mode
Already on blocking
timo damn, that's nice 12:45
jnthn Looks like there'll be a small number of spectest failures to look in to 12:47
brrt 1/2 timo :-o 12:48
timo oh no!
brrt jnthn++
timo that's why i don't feel so good today
brrt clearly
timo it's kind of surprising to see "timo" be free on freenode 12:49
Last seen : Apr 09 14:33:37 2018 (13w 0d 22h ago) 12:50
Geth MoarVM/du-chains-and-opts: 2649fadef0 | (Jonathan Worthington)++ | 2 files
Correct handling of inc/dec usage
 13:12
MoarVM/du-chains-and-opts: acf361f9b5 | (Jonathan Worthington)++ | src/spesh/dead_bb_elimination.c
Remove outdated comment
timo campaign to turn inc and dec into sp_inc and sp_dec while building the graph which is a two-operand version ... 13:13
and on codegen if both registers have stayed the same we turn it back again :P 13:14
jnthn :P 13:17
D'oh, so it turns out the problem seems to be that a second-pass opt is to blame, and normally we'd not check those, but if we produce an inline from an unspecialized then we do 13:18
And I know full we'll `set` opts are totally cheating on the SSA form and thus on usage chains too
timo ooh
jnthn And all the Rakudo spectest complaints about broken graphs that I looked at seem to stem from that
timo are the set opts really worth much anyway? 13:19
jnthn Hm, it may actually not be them in the immediate problem case :) 13:20
They're worthwhile, but need doing proper :)
Though actually the immediate thing to blame seems to be something else :) 13:22
Hm, and now I fixed that the set stuff doesn't seem to casue the upset I expected :) 13:24
Geth MoarVM: c7627e5113 | (Samantha McVey)++ | 3 files
Use platform/stdint.h instead of making own int const macros

  brrt++ informed me about this. Use this instead of rolling our own.		 13:25
MoarVM/du-chains-and-opts: 098b7fa4a6 | (Jonathan Worthington)++ | src/spesh/optimize.c
Mark throwcat result as dead writier when goto'd

If it's possible to rewrite into a `goto`, then we know there's no possible way we can do a resume. Mark any uses of the result as being from a dead writer.		 13:28
MoarVM/du-chains-and-opts: ba0a2447c0 | (Jonathan Worthington)++ | src/spesh/optimize.c
Add DU chain checks after second stage opts too
 13:29
jnthn Rakudo seems much happier now
Saw a SEGV then realized I fixed that in master yesterday, but this branch started before then
nwc10 rebase!
neuralise it
lizmat what? 13:30
nwc10 nothing. :-)
(the branch)
jnthn Yeah, will do :)
dogbert17 well, there's a SEGV in t/spec/S06-advanced/callframe.t
jnthn Yes, that and indir.t :) 13:31
dogbert17 :)
jnthn Those are the ones I expect a rebsae to clean up
dogbert17 aha
there's also a 'MoarVM oops: Malformed DU chain: writer goto of 44(7) not in graph'
jnthn yeah, both of them :)
Yes, that one is from the throwcat issue I fixed above 13:32
dogbert17 oops, you commit too fast :-)
jnthn I'll force-push the rebase, so if you have a checkout of the branch, you'll need a new one 13:33
Geth MoarVM/du-chains-and-opts: 38 commits pushed by (Jonathan Worthington)++, (Timo Paulssen)++
review: github.com/MoarVM/MoarVM/compare/b...6d9f829b0f		 13:34
jnthn does another spectest with that 13:35
dogbert17 things are looking much better now 13:37
jnthn Yeah, seems so 13:39
Only t/spec/S06-currying/positional.t is in trouble now 13:42
MoarVM oops: Malformed DU chain: reading dec_i of 30(64) not in graph 13:43
tssk
dogbert17 spesh of 'term:sym<name>' (cuid: 507, file: gen/moar/Perl6-Grammar.nqp:3508)
Geth MoarVM/du-chains-and-opts: 2fb1bd860f | (Jonathan Worthington)++ | src/spesh/manipulate.c
Fix dec_u/dec_i handling in BB deletion
 13:46
jnthn That fixes it
13:48 Kaiepi left, Kaiepi joined
jnthn Now for NODELAY 13:49
Geth MoarVM/du-chains-and-opts: cf2ed18c24 | (Jonathan Worthington)++ | 2 files
Mark native ref ops as :useshll

Fixes a spectest regression under NODELAY.		 14:07
jnthn That's not related to the DU-chain things really :) 14:08
dogbert17 looks, really good. I do see an asan complaint wrt t/concurrency/01-thread.t but I don't really know if it's realated to your current work or if it's something old 14:16
jnthn Old, I think 14:17
dogbert17 I think so too 14:19
lizmat ok, how do I check whether I have a Sub in a QAST::WVal: nqp::istype($wval.value,Sub) doesn't seem to cut it ? 14:20
jnthn Where are you doing this? 14:21
You probably need to look up Sub
lizmat ah, good point
R#2040 , fwiw
synopsebot R#2040 [open]: github.com/rakudo/rakudo/issues/2040 no warning for Callable in sink context
14:31 Kaiepi left 14:32 Kaiepi joined 14:40 Voldenet joined, Voldenet left, Voldenet joined
Geth MoarVM/du-chains-and-opts: 067b103045 | (Jonathan Worthington)++ | src/spesh/optimize.c
Add a couple of missing use_facts calls
 15:16
jnthn So interesting 15:18
I discovered that while we were logging what came out of a decont, we were then never actually using those logged stats
So I tried that out.
And boom, exploding Rakudo on `use Test` 15:19
Turns out the above commit fixes it
15:19 brrt left
timo sweet 15:20
jnthn And stresstest passes with spesh blocking turned on
This can have some dramatic effects
For example, `my $foo = "blah"; for ^10_000_000 { my int $i = $foo.chars }` could not resolve .chars at spesh time there 15:21
Now it can
timo *nice*
jnthn So instead of taking 2.48s it resolves it, inlines it, and takes 0.90s
lizmat whee
jnthn I discovered this because I was going to use this example as a box/unbox elimination example
To see if I could use the du-chains to deal with those 15:22
And then discovered that it wasn't even inlining chars
Geth MoarVM/du-chains-and-opts: b8e9de82d6 | (Jonathan Worthington)++ | 2 files
Turn on used of logged stats for decont

Which lets us insert guards and optimize things that we could not prior to this change.		 15:23
dogbert17 I suddenly get one test failing in t/05-messages/10-warnings.t 15:52
not ok 2 - no useless-use warning on return when KEEP/UNDO phasers used 15:53
16:00 brrt joined
jnthn grr, another attempt to tidy things up rumbled by deopt 16:03
16:39 robertle left 16:44 domidumont left
lizmat dogbert17: I'm on it, my bad 16:51
lizmat should learn to not just run spectests 16:52
dogbert17: fixed 17:02
jnthn has been tweaking Rakudo signature compilation a bit
So we can do one decont, not a load of them
17:02 Kaiepi left
jnthn Got it a bit nicer at least 17:02
17:02 Kaiepi joined
jnthn Though the patch blows up a handful of spectests, so will have to look at that first. 17:03
17:12 brrt left
Geth MoarVM/du-chains-and-opts: e838ff93c9 | (Jonathan Worthington)++ | 4 files
Add a maycausedeopt annotation

We'll use this to know when there's actual risk of deopt in the code after we've optimzied it, but before we go doing dead instruction elimination. Often, many potentially deopt-causing things go away due to the devirtualization, and some log guards are simply unused. Doing a post-optimization analysis will thus be more precise, and this new annotation provides the tools to drive it.		 17:24
dogbert17 lizmat++: it works again 17:26
jnthn Enough for today :)
dogbert17 cooking time perhaps?
jnthn Well, for this side of the game anyway
Yeah, well, warming time, as I cooked aloo gobi for two days yesterday :)
dogbert17 clever move :) 17:27
jnthn bbl o/
17:46 domidumont joined
Geth MoarVM/du-chains-and-opts: 0cb8ab0270 | (Elizabeth Mattijsen)++ | src/core/oplist
Fix typo, ven++
 17:51
timo that's menasing 17:53
TimToady the edn justifies the menas 18:03
18:03 AlexDaniel joined
lizmat just things you're all mena 18:17
*thinks
argh :-)
18:37 Kaiepi left 18:39 Kaiepi joined
[Coke] lizmat: as long as you're in there; "other site" ? could be right, but maybe it meant "other side" ? 18:54
19:14 domidumont left 19:21 timo is now known as timotimo 19:45 buggable joined 20:11 Kaiepi left, Kaiepi joined 20:13 Kaiepi left, Kaiepi joined
lizmat [Coke]: no, I think "site" is meant 20:26
hmmm... maybe you're right 20:27
jnthn: ^^
20:39 brrt joined 21:54 MasterDuke joined
brrt hmm, any way I can get a list of STables so that I can print their size 21:54
timotimo STables have fixed size, but the REPR_data might be more interesting 21:55
brrt hmm 21:58
i'm thinking i need the type_object_for thing
timotimo i'm not sure what you're trying to do so don't know what to suggest :) 21:59
brrt I want to get a table of MoarVM repr sizes 22:06
so that I can calculate the expected waste from aligning to 64 byte
jnthn [Coke]: Yes, side in this case, though (call)site is a commonly used term in spesh stuff too 22:07
brrt: Do a heap profile, hack the heap profile analysis tool up to tell you that :)
But that doesn't tell you about the nursery content so much 22:08
brrt hmm. that might've been a simpler way
timotimo oh 22:09
maybe use heaptrack and see how many how-big allocations happen from functions that create REPR_data? 22:10
brrt hmm, REPR_data is another pointer anyway 22:11
so i'm not too concerned about that
it appears I overestimated the size of the object header 22:14
ok, i'm confused 22:18
oh, i'm unconfused, i'm printing as hex
duh 22:33
ok, i have a table of repr sizes, yay
23:00 brrt left
jnthn I think I might finally have a small "keep less for deopt" optimization that is decidedly limited and conservative, but will at least help a bit. 23:22
timotimo cool, tell us about it :) 23:27
or just push the commit with the commit message i'm sure you'll craft masterfully
jnthn Unfortunately, we do a crappy job of maintaining our preds when deleting basic blocks 23:40
And so my "it's OK" was bogus because it was doing rather less than it should have been
So currently re-testing.
NQP build/test with blocking spesh is happy with the new version; Rakudo is working on the setting at the moment 23:41
23:43 lizmat left
jnthn make test is OK, make spectest running 23:46
timotimo i'm not sure what your "it's ok" refers to, but i'll find out soon enough 23:53
Geth MoarVM/du-chains-and-opts: 2bab220aff | (Jonathan Worthington)++ | 3 files
Decrease instructions kept for potential deopt

We have to retain various instructions that are otherwise unused for the sake of deopt. Eliminating these is rather delicate in general. However, it's certain that any linear sequence of non-deopting instructions at the end of the graph cannot possibly be impacted by a deoptimization, since there is none that can take place. Thus, walk backwards over those instructions, clearing their "required for deopt" markers.		 23:57
timotimo oh, not bad 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!