github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke ugh, i've never had much luck with asan 01:39
how does everyone else build with it?
moarvm compiled just fine, but i couldn't run my already-built rakudo, so i tried building nqp and rakudo again but the nqp build dies 01:40
some valgrind output gist.github.com/MasterDuke17/11f34...996c343c8e 01:50
moarvm was built with `--debug=3 --telemeh --valgrind --optimize=0` 01:55
.tell jnthn a question about asan, but then some valgrind output colabti.org/irclogger/irclogger_lo...9-04-12#l3 02:34
yoleaux MasterDuke: I'll pass your message to jnthn.
jnthn morning o/ 09:18
yoleaux 02:34Z <MasterDuke> jnthn: a question about asan, but then some valgrind output colabti.org/irclogger/irclogger_lo...9-04-12#l3
jnthn No Geth here, but I just rebased more-pea 09:36
jnthn MasterDuke: I just pass --asan to MoarVM's Configure.pl 09:50
Geth MoarVM/more-pea: ac00512c44 | (Jonathan Worthington)++ | src/spesh/pea.c
Fix a use-after-realloc
09:59
jnthn That gets rid of at least the bit of ASAN unhappiness with that branch that was reported
jnthn Now spectests clean with ASAN enabled and MVM_SPESH_BLOCKING=1 10:13
Guest16965 jnthn: does this work? MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ASAN_OPTIONS=detect_leaks=0 ./perl6 t/spec/S32-array/delete-adverb-native.t 10:59
jnthn Yes 11:01
Guest16965 jnthn++ 11:26
jnthn Mmm...'twas a nice Vietnamese lunch :) 12:13
Guest16965 is a merge imminent? 12:15
jnthn I did a merge this morning into Rakudo of the work to reduce the number of return handlers 12:16
m: say 14689160 - 14516680
evalable6 172480
timotimo core setting size? 12:17
jnthn 172 KB off CORE.setting size form that :)
timotimo sweet
Guest16965 rebuilds
jnthn And the JIT code for an array indexing operation shrunk by over 300 bytes too in recent changes 12:18
Geth MoarVM: c10fee65c8 | (Jonathan Worthington)++ | 9 files
Handle inlining of outer lexical binds

This is used in code using native types, and was one source of surprise slowness when using natives. For example, this:
   my num $x = 1.5e0;
   my num $y = 0e0;
... (8 more lines)
13:04
Guest16965 jnthn: did the last commit fix R#2333 by any chance? 13:14
jnthn Potentially 13:15
Guest16965 doesn't look like it 13:16
jnthn There's perhaps more going on there 13:17
Guest16965 making $total an int makes the code run at almost half speed. Odd 13:19
timotimo where does $total come from? 13:20
you mean $y?
jnthn He's talking about the code in the issue, not the one I just pasted
timotimo ah
oh, synopsebot is also not there
jnthn Well, I assume Guest16965 is dogbert... :)
timotimo R#2333 13:21
synopsebot R#2333 [open]: github.com/rakudo/rakudo/issues/2333 [performance] Unexpected perf result with native math assignment
Guest16965 jnthn: :-)
new work computer, haven't had time to set things up properly yet 13:22
timotimo does that still build NativeRef all the time?
jnthn timotimo: Probably.
Currently looking at making the EA deal with Int, which is quite tricky because it's not a straight boxing. 13:23
timotimo right
we don't have bigint as a type-ish thing
so can't go into o register
jnthn Yeah, well, my plan is to add a .bi register type that only spesh can deal with 13:24
*but* lifetime management is taking some figuring out
Since there's potentially a malloc'd object in there
And we need to not leak nor double-free those
Guest16965 the slow version allocates 1_000_000 IntLexRef, the fast version allocates zero IntLexRef 13:30
jnthn That'll be the answer then
timotimo aye, same as before, sadly
Geth MoarVM/more-pea: eb48ea1e74 | (Jonathan Worthington)++ | 2 files
Introduce two new register kinds (spesh use only)

This is in preparation for dealing with P6bigint (and thus Perl 6 Int values) in the escape analysis. The two are:
  * Referenced big integer: big integer value that is copied out of an
   owning object
  * Owned big integer: big integer object that is currently not owned by
   any all allocated box object, and so needs to be cleared up at scope
   exit
13:51
timotimo all allocated, mhm
jnthn oops :) 13:53
Geth MoarVM/more-pea: e4d5368485 | (Jonathan Worthington)++ | tools/update_ops.p6
Recognize new rbi/obi regs in op update tool
14:52
Woodi yo 15:43
C++ have RVO optimisation and looks like using pointer to variable that will be assigned when function returns. so function do not need to create tmp value + one less copy... do we have such thing in Moar ? en.wikipedia.org/wiki/Copy_elision 15:44
jnthn Perl 6 example where such an optimization might apply? 15:51
jnthn Certainly if you do things like `$foo.bar.baz` and we inline both bar and baz then the output of one can, deopt allowing, be used directly in the second without need of storing the value in the register of the caller 15:52
Not sure if that counts as such a case, though (I barely read C++ :)) 15:53
Woodi jnthn: I thinked that RVO "inlines" varible from outer func into inner func by replacing creating temp variable with pointer to container from outer... 15:55
Woodi but probably /me just theoretizing... 15:57
Geth MoarVM/more-pea: 8c2a1bad93 | (Jonathan Worthington)++ | 5 files
Stub in some proposed unboxed big int ops

These will be used as part of the big integer EA unboxing work.
17:25
MoarVM/more-pea: 5b847bdd94 | (Jonathan Worthington)++ | src/spesh/pea.c
First steps towards SR with big integers

This adds the algorithm to scalar replace various (for now, only very carefully constructed) cases of objects boxing big integers. This will not yet work; the ops it rewrites things into are unimplemented, and the freeing of any allocated big integers is not yet implemented, so they will be leaked.
timotimo hm, does that mean we'll have to have an sp variant of every big int operation, too? 17:32
wait
timotimo actually reads the commit
timotimo i see, there's a few of them there right now 17:33
jnthn timotimo: Yes, probably, though I plan to get rid of the sp_add_I series in favor of the sp_add_bi and similar, I think... 19:10
timotimo ah, that makes sense, can always make those by putting an unbox in front 19:58
maybe we'll be able to reason in the JIT that some bigint was actually small and we don't have to check twice in a row or something 20:02
MasterDuke jnthn, timotimo: do my valgrind outputs from last night look useful? 23:21
jnthn MasterDuke: They didn't give me any immediate guesses 23:33
MasterDuke jnthn: hmm, too bad. when you build with --asan, do you have to rebuild nqp/rakudo? 23:38
jnthn nqp, no; Rakudo it seems since the new runner, yes 23:43
Though if using ./perl6-m I think that's still the hell script
uh, *shell :D
MasterDuke ha 23:44
timotimo there is also a flag to configure that makes it not do that, iirc
"--no-relocatable" maybe 23:45
MasterDuke huh. i rebuilt moar with `--asan --compiler=clang`. trying to run perl6-m gives `./install/bin/perl6-m: symbol lookup error: /home/dan/Source/perl6/install/bin/../lib/libmoar.so: undefined symbol: __asan_option_detect_stack_use_after_return` 23:48
and then trying to rebuild rakudo gives gist.github.com/MasterDuke17/f9358...7f673775b6 23:49
same behavior in kubuntu 18.10 with clang 7.0.0-3 and arch linux with clang 8.0.0 23:53
but i've had this behavior since way before the relocatable work 23:54