github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
Geth MoarVM/postrelease-opts: 4 commits pushed by (Jonathan Worthington)++ 09:33
jnthn Just a rebase so I've got the fix from master :)
brrt hmm, i wanted to add a MVM_VECTOR_DESTROY and ended up rewrting to use alloca 10:05
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
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
brrt hmm, we should probably fix that 10:54
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
jnthn So the set elimination opt can change a guard instruction such that its input and output are different 12:47
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
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
jnthn Cool, next year's TPC Europe is in Riga! :D 13:20
That's probably a fun train journey :) 13:22
Geth MoarVM/postrelease-opts: 981a180568 | (Jonathan Worthington)++ | 2 files
Mark [sp_]speshresolve as :invokish
 13:25
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!
tadzik ooh, Riga again, nice :) 13:48
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.
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
timotimo depending on the data passed in, the actual behaviour of routines below that could be anything 15:13
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
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
nine Oh, yes, I meant disappeared :) 15:52
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 :)
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 :)
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
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
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
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
Geth MoarVM/postrelease-opts: ae2832d09c | MasterDuke17++ (committed using GitHub Web editor) | src/spesh/optimize.c
Fix typo in comment
 18:22
MasterDuke samcv: you usually use clang, right? have you seen github.com/rakudo/rakudo/issues/2124 happen on your system? 21:30
samcv MasterDuke: yeah i use clang 22:19
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!