github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:12 MissionCritical joined 00:15 regreg left 00:17 MissionCritical left 01:37 yaymuffins24 joined 01:39 yaymuffins24 left 02:38 bitch24 joined, bitch24 left 02:47 Auctus0 joined, Auctus0 left 04:07 Selfsigned11 joined 04:09 Selfsigned11 left 04:29 regreg joined, p6bannerbot sets mode: +v regreg 04:36 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 04:49 nate23 joined 04:52 nate23 left 05:00 Cronus19 joined 05:01 Cronus19 left 05:04 biberao0 joined, slackjeff joined 05:07 slackjeff left 05:08 biberao0 left 05:49 zopsi21 joined, zopsi21 left 06:15 suim4 joined 06:19 suim4 left 06:30 ZzZombo left 06:31 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 06:43 bjs4 joined, bjs4 left 07:30 norkle7 joined 07:31 norkle7 left 07:35 zakharyas joined 07:36 p6bannerbot sets mode: +v zakharyas 07:39 regreg left 07:57 K0HAX15 joined 07:58 K0HAX15 left 08:00 lizmat left 08:22 brrt joined 08:23 p6bannerbot sets mode: +v brrt
brrt \o 08:30
i'm seeing a bunch of MVM_oops that I think can be assert 08:31
jnthn But asserts ain't included in non-debug/optimized builds, I think? 09:09
yoleaux 00:40Z <Xliff> jnthn: What do you think of va_list conversion to NativeCall?
brrt that's the point :-)
jnthn Well, it ain't my point. :P 09:15
If we're going to do something awful, I'd prefer we do so with a message than can be reported back to us that gives us a hint at what went wrong 09:16
brrt so, my thought was, when that happens users are lost anyway 09:18
jnthn Note that on especially hot paths we do have debugging asserts 09:19
So it's not that we aren't using them already, just that it's a trade-off between the failure information we can produce and performance
09:20 nativecallable6 left, statisfiable6 left, greppable6 left, greppable6 joined, statisfiable6 joined, nativecallable6 joined, committable6 left 09:21 shareable6 left, benchable6 left, p6bannerbot sets mode: +v greppable6, p6bannerbot sets mode: +v statisfiable6, p6bannerbot sets mode: +v nativecallable6 09:28 lizmat joined 09:29 p6bannerbot sets mode: +v lizmat
Geth MoarVM/postrelease-opts: 4 commits pushed by (Jonathan Worthington)++ 09:33
jnthn Just a rebase so I've got the fix from master :)
09:48 brrt left, brrt joined 09:49 lizmat left, p6bannerbot sets mode: +v brrt
brrt hmm, i wanted to add a MVM_VECTOR_DESTROY and ended up rewrting to use alloca 10:05
10:08 lizmat joined 10:09 p6bannerbot sets mode: +v lizmat 10:10 lizmat left
Geth MoarVM: 86ba33728a | (Bart Wiegmans)++ | src/spesh/manipulate.c
[Spesh] Change MVM_VECTOR to alloca

Since we know at function entry how many basic blocks there are, we can allocate a fixed size buffer, and because we use alloca, we don't have to free it either.		 10:11
brrt has done all too much size bounds analysis in the expression JIT for sanity, but it does sometimes pay off :-) 10:14
10:14 Random27 joined 10:17 lizmat joined, p6bannerbot sets mode: +v lizmat 10:18 committable6 joined, shareable6 joined, Random27 left 10:19 p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v shareable6 10:20 regreg joined, p6bannerbot sets mode: +v regreg 10:22 justache4 joined 10:24 justache4 left 10:25 lizmat left 10:27 ZzZombo left 10:31 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Bart Wiegmans '[Spesh] Change MVM_VECTOR to alloca 10:31
travis-ci.org/MoarVM/MoarVM/builds/416296753 github.com/MoarVM/MoarVM/compare/d...ba33728a34
10:31 travis-ci left 10:46 DLange24 joined 10:48 DLange24 left
brrt hmm, we should probably fix that 10:54
10:54 lizmat_ joined 10:55 p6bannerbot sets mode: +v lizmat_ 11:08 batman4216 joined 11:09 batman4216 left 11:13 brrt left 11:31 zakharyas left 11:32 bjs26 joined 11:34 stmuk joined 11:35 p6bannerbot sets mode: +v stmuk 11:37 bjs26 left, stmuk_ left 12:13 lizmat_ left 12:15 ^Phantom^18 joined 12:19 ^Phantom^18 left
jnthn Uff...this deopt bug is hard to hunt down :S 12:20
(It's exposed by the latest change in postrelease-opts, and there's no known cases of it manifesting in master, but I don't yet know what it is) 12:24
Ah, apparently lunch helped, I think I mighta found it 12:32
timotimo hooray for lunch! 12:37
i'm glad you're the one we entrusted the lunch codes to 12:38
jnthn tssk, apart from the fix breaks other things :S 12:43
12:44 brrt joined 12:45 p6bannerbot sets mode: +v brrt 12:47 zakharyas joined
jnthn So the set elimination opt can change a guard instruction such that its input and output are different 12:47
12:47 p6bannerbot sets mode: +v zakharyas
jnthn However we always wrote the output register whether or not we deopt'd 12:48
Changing it so we do that only if we aren't going to deopt fixed things. But it breaks other things.
But I've got deopt analysis being done after guard insertion. But guard insertion meddles with the SSA form. 12:49
Well, not the SSA form, it's still valid
But different versions show up either side of the guards
I'm wondering if that means deopt analysis coming after guard insertion makes it "too late"
timotimo optimization ordering again, huh 12:51
jnthn I guess the way to find out is to do 1) a usage pass, 2) deopt pass, 3) facts and guard insertion pass
And see if that helps 12:52
Of course, making the `set` optimization never touch a guard instruction is another option, but that feels like we'll just hit the same problem again in a different opt later on 12:53
13:03 rosseaux6 joined 13:04 diakopter joined, p6bannerbot sets mode: +v diakopter, rosseaux6 left, lizmat joined 13:05 p6bannerbot sets mode: +v lizmat
jnthn That may well have helped, though will keep quite until I see lots of passing tests :) 13:12
It's not so much optimization ordering as making sure that we get our deopt info gathered early enough and then take great care to honor it 13:15
timotimo OK 13:16
jnthn I'd thought we could get away with doing it a tad later so we could merge a couple of passes
I was wrong
Now we gather it as early as we possibly could
Yay, test and spectset pass 13:18
13:19 brrt left, brrt joined 13:20 p6bannerbot sets mode: +v brrt
jnthn Cool, next year's TPC Europe is in Riga! :D 13:20
That's probably a fun train journey :) 13:22
13:25 lizmat_ joined
Geth MoarVM/postrelease-opts: 981a180568 | (Jonathan Worthington)++ | 2 files
Mark [sp_]speshresolve as :invokish
 13:25
13:26 p6bannerbot sets mode: +v lizmat_
Geth MoarVM/postrelease-opts: 3a18f3b38c | (Jonathan Worthington)++ | 3 files
Form deopt usage information before guard inserts

Otherwise, now that guards have a read and a write register, we can end up with the information being insufficiently accurate in order to keep things alive as needed for deopt.		 13:28
MoarVM/postrelease-opts: 0f46730b2f | (Jonathan Worthington)++ | 2 files
Only write guard write regsister if not deopting

Otherwise, we might end up scribbling over a register that holds a useful value the other side of deopt, which can happen under our move aggressive `set` elimination optimizations, but potentially in others too.
jnthn langauge class &
timotimo have fun!
13:28 lizmat left
tadzik ooh, Riga again, nice :) 13:48
14:07 lizmat_ left 14:09 lizmat joined 14:10 p6bannerbot sets mode: +v lizmat 14:17 lizmat left
Geth MoarVM/spesh-leaks: 6104e045cf | (Bart Wiegmans)++ | src/moar.c
[FSA] Fix use-after-free in cleanup

If we cleanup the main thread (with it's per-thread FSA free list) after cleaning up the FSA itself, that corresponds to a use-after-free, and we should not.		 14:18
MoarVM/spesh-leaks: 02ecc6bf77 | (Bart Wiegmans)++ | 8 files
[Spesh] Destroy inlinee after inlining

After we've inlined a graph the inliner claims ownership over the memory of the inlinee. With this patch, we destroy the original graph, which should simplify lifetime management. The memory region list is merged with the inliners graph so that the memory allocated for the inlinee nodes is not freed.
MoarVM/spesh-leaks: 06bd801563 | (Bart Wiegmans)++ | 2 files
[Spesh] Leak fixes

Many allocated things either come from a spesh candidate or from malloc (or realloc). Or they are assigned to a spesh candidate. So the only way to really know if they are shared with a spesh candidate
  (or static frame) is by checking if they are pointer-equal.
ASAN leaksanitizer is finally clean now for me.
14:27 brrt left 14:37 regreg left 14:38 lizmat joined 14:39 p6bannerbot sets mode: +v lizmat 14:46 spirit_pact0 joined 14:51 spirit_pact0 left
timotimo i blagged! wakelift.de/2018/08/15/the-first-p...c-release/ 14:52
lizmat weekly: wakelift.de/2018/08/15/the-first-p...c-release/ 14:54
notable6 lizmat, Noted!
jnthn timotimo: Nice post 15:11
timotimo thank you!
jnthn And nice work :D
timotimo \o/
jnthn About the Inclusive Allocations
For Str it looks like we allocate more per entry after spesh
timotimo i might have to double-check how that comes to be 15:12
if i'm properly summing up spesh/jit entries
perhaps it barfs if there's some calls with only spesh and some with also jit?
jnthn Dunno, it just seems odd
timotimo oh, i probably divide it by the entries to the routine on that page 15:13
15:13 lizmat left
timotimo depending on the data passed in, the actual behaviour of routines below that could be anything 15:13
15:14 lizmat joined, lizmat left
timotimo and perhaps it doesn't even make sense to give a "per entry" count there 15:14
nine Huh? Somehow much of the slowdown caused by hllbool has appeared over night. Now I think I may just have run a debug version of moar
timotimo isn't that the opposite of what should happen? :o 15:15
jnthn Maybe disappeared? :) 15:16
timotimo that'd be a good explanation 15:19
15:26 lizmat joined 15:27 p6bannerbot sets mode: +v lizmat 15:30 dogbert11 left 15:40 pppingme9 joined
Geth MoarVM/postrelease-opts: 4e0ae266d0 | (Jonathan Worthington)++ | 3 files
Propagate facts of inlined return value to inliner

In preparation for looking at eliminating unrequired guards. This is a common case where we will often be able to do guard elimination.		 15:48
15:49 pppingme9 left
nine Oh, yes, I meant disappeared :) 15:52
15:54 dave492514 joined 15:57 dave492514 left
jnthn timotimo: How did your proven guards elimination patch misbehave, ooc? 15:57
timotimo hm, let me try again 16:00
jnthn Well, I've got it applied in my postrelease branch which means on top of various fixes
And so far it built NQP and passed tests, built Rakudo and passed tests, and now I'm doing spectest and it doesn't look bad so far 16:01
timotimo right, you want something that used to break so you can compare?
jnthn Plus I checked the code in a microbenchmark where I expected it to apply and it worked
So it's certainly tossing guards
ah, I think I just saw one failure in spectest 16:02
ah, but they both failed before this change 16:03
ah, one of 'em fails with spesh disabled 16:06
So it's just a busted spectest I guess
The other is a SEGV
timotimo actually i don't see it fail stuff any more even though i don't have the latest fixes 16:07
jnthn hm, odd :)
timotimo but maybe that was when i turned guardtype into guardjusttype which the commit i pushed doesn't do?
jnthn maybe
I'll drop that bit for now and clean it up and push it 16:08
timotimo t/spec/S03-operators/buf.t ........................................ Dubious, test returned 255 (wstat 65280, 0xff00) 16:09
doesn't happen to be this one?
jnthn No, that's just being behind Rakudo HEAD 16:10
timotimo OK
one thing that surprised me was that the post-guarded register seemed to have many more fact flags set than the pre-guarded register 16:11
wait, was that from a commit that was actually pushed to master?
* 37b7c7b79 - discover facts about a bunch of sp_guard ops (5 days ago) <Timo Paulssen> 16:12
jnthn yeah, I did git pull of Rakudo earlier today and that problem went away
timotimo right, that's in there
Geth MoarVM/postrelease-opts: 877054f600 | (Timo Paulssen)++ (committed by Jonathan Worthington) | src/spesh/optimize.c
Turn redundant sp_guard* ops into set

We can eliminate them when we can prove that the guard will always be true.
nine Oh....the expr JIT template for hllizefor may actually cause a slow down! Unlike the lego JIT version it will always run MVM_hll_get_config_for even if the HLL name is a known values (which it probably is always) 16:14
timotimo right :( 16:15
i think hll configs might actually be non-moving 16:16
so you can "just" put the address into an i64 register (hopefully properly truncated on 32bit)
and treat it as a pointer on the other end
by writing something like sp_hllizefor that takes an extra argument
jnthn Yeah, they don't move
And while you can't put them into a spesh split 16:17
You could put the true and false into spesh slots
And then JIT it into something involving those
timotimo this is for hllizefor in general i think?
jnthn With some sp_ternery
Oh, I thought for hllboolfor :)
nine And the template for hllize always calls MVM_hll_current while the Lego JIT version determines the pointer at compile time. 16:24
timotimo that's why we could generate a different instruction that has the current hll in its arguments :) 16:25
nine getcurhllsym just does (let: (($hllname (^getf (cu) MVMCompUnit body.hll_name))) 16:27
Geth MoarVM/postrelease-opts: 7668b82efd | (Timo Paulssen)++ (committed by Jonathan Worthington) | src/spesh/optimize.c
Turn redundant sp_guard* ops into set

We can eliminate them when we can prove that the guard will always be true.		 16:29
jnthn Ammended version with a fix :)
16:31 brrt joined
timotimo trying to see the difference 16:32
failing
the only thing i see is that char *name was thrown out, because it was unused after the debug printfs have disappeared
jnthn Yes, that's what I removed
timotimo oh, ok!
jnthn I noticed it 'cus it discarded a const and so produced a warning :)
16:32 p6bannerbot sets mode: +v brrt
brrt .tell nine that's an interesting case for the jit optimizer... I want to make it so that we can use spesh facts that correspond to nodes 16:40
yoleaux brrt: I'll pass your message to nine.
brrt and maybe do some constant folding
timotimo i think we may want to have a bit more extra information
because we know for example that anything that hangs off of an STable can be considered constant up to a certain point
but how do we encode that in the jit itself? 16:41
16:43 lizmat left
brrt not in the jit, but in the optimizer, that's possible 16:47
anyway, i'll have to think about it some
timotimo++ interesting post 16:48
timotimo thanks :) 16:49
17:00 vegii20 joined 17:02 nolsen14 joined 17:03 vegii20 left
Geth MoarVM/postrelease-opts: ce5b2557ad | (Timo Paulssen)++ | src/spesh/graph.c
insert null-register-ops in ascending order
 17:05
timotimo there's also this commit
17:06 nolsen14 left
Geth MoarVM/postrelease-opts: f4d93bcf96 | (Jonathan Worthington)++ | src/spesh/optimize.c
Clear up and start improving box optimization

  * Remove seemingly non-effective box and dead code unbox opts in the
   first optimize pass
  * In the second optimize pass, introduce code to delete dead box
   instructions that are rendered no longer required due to box/unbox
   pair elimination
... (7 more lines)		 17:08
jnthn dinner &
timotimo i like that we have pips now 17:14
Geth MoarVM: bdw++ created pull request #941:
Fix Spesh Memory Leaks		 17:18
17:24 brrt left 18:05 zakharyas left
Geth MoarVM/postrelease-opts: ae2832d09c | MasterDuke17++ (committed using GitHub Web editor) | src/spesh/optimize.c
Fix typo in comment
 18:22
18:46 cheshire_cat joined 18:49 cheshire_cat left 19:57 zakharyas joined, p6bannerbot sets mode: +v zakharyas 20:37 zakharyas left 20:54 bobe11 joined, bobe11 left
MasterDuke samcv: you usually use clang, right? have you seen github.com/rakudo/rakudo/issues/2124 happen on your system? 21:30
22:18 robertle left
samcv MasterDuke: yeah i use clang 22:19
22:20 lizmat joined 22:21 p6bannerbot sets mode: +v lizmat
Geth MoarVM/postrelease-opts: 05a43615bf | (Jonathan Worthington)++ | 2 files
Lower box_[ns] with P6opaque

This covers boxing of both Num and Str objects in Perl 6, lowering them into a fastcreate and a p6o_bind_[ns], which avoids a C call and the indirections and checks that the normal code has to do.		 22:41
MoarVM/postrelease-opts: a89b74c5a8 | (Jonathan Worthington)++ | src/spesh/optimize.c
Do a dead instruction pass after post-inline pass

This clears up things like hllboxtype instructions left behind by lowered or deleted boxing instructions.
jnthn m: say 1.234 / 1.367 22:43
camelia 0.902707
jnthn 10% off `my $n = 0e0; for ^10_000_000 { $n = $n + 1e1 }; say $n` 22:44
m: say 7.128 / 7.638 22:54
camelia 0.933229
jnthn That's for `my $x = "food"; for ^10_000_000 { $x.tc.flip }` but the code-gen for that is utterly shite 22:55
But that can be a problem for another day :)
MasterDuke i set a breakpoint in gdb while compiling an nqp file, is there an easy way to see what line in the file i'm compiling i'm at? 23:32
timotimo MasterDuke: perhaps a start to figuring this otu would be to call MVM_dump_bytecode and see if that gives you a hint 23:39
i often combine that with looking at a current spesh log 23:40
MasterDuke timotimo: hm. i set a breakpoint in MVM_coerce_smart_numify and then called MVM_dump_bytecode, but nothing jumps out at me 23:43
oh, the the annotations might be helpful... 23:44
timotimo exactly 23:45
though you could also try manually getting the annotation
MasterDuke huh, no annotation in this bytecode 23:46
timotimo dump_bytecode doesn't output them i don't think 23:47
MasterDuke i did see them the first time i ran it
oh, the annotation look like they're pointing to the location of the code that's getting run, not that's being processed 23:49
timotimo processed, eh? 23:50
MasterDuke well, parsed/interpreted/something 23:51
timotimo ah, yes, you would have to inspect the lexicals and such for that to work 23:52
that'd be a lot easier with the debugserver, bu tit's not made to handle the use case of "code was stopped in gdb, figure it out!"
MasterDuke yeah, the annotations are pointing to num processing code, which makes sense, but i want to see why that code is being called 23:53
you know, i still haven't used the debugserver yet
it would help for this?
timotimo you can find the callers with MVM_dump_bytecode_frame(tc, 1) and higher numbers iirc
well, you can use it to navigate the call stack as well as outers of frames and through items and containers and such 23:54
MasterDuke *_bytecode_of or *_bytecode_staticframe?
timotimo bytecode_of, i think 23:55
MasterDuke oh, i missed _stackframe, that looks like it
afk for a bit, but thanks, that looks like it'll help 23:57
23:58 Hobby12 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!