dalek arVM: d2621b2 | (Jimmy Zhuo)++ | / (3 files):
small optimization
 03:20
timotimo JimmyZ: when is that code actually being run, OOC? 11:09
JimmyZ timotimo: don't know, but make MASTOps.moarvm size about 8% smaller 11:11
timotimo oh. that's not so bad :) 11:13
jnthn I'm surprised you didn't have to chance the indexer to an nqp::atpos_s
JimmyZ hmmm, I think it should change to atpos_s 11:14
jnthn *change
nqp: my $s := nqp::list_s('abc'); say($s[0]); 11:15
uh...
jnthn nqp: my $s := nqp::list_s('abc'); say($s[0]); 11:16
m: say 'alive?' 11:17
Hm.
camelia ..nqp-parrot: OUTPUT«Can't exec "./rakudo-inst/bin/nqp-p": No such file or directory at lib/EvalbotExecuter.pm line 188.␤exec (./rakudo-inst/bin/nqp-p /tmp/tmpfile) failed: No such file or directory␤Server error occurred! Closing Link: ns1.niner.name (Quit: camelia)␤Lost connect…»
..nqp-moarvm: OUTPUT«MVMArray: atpos expected string register␤ at /tmp/tmpfile:1 (<ephemeral file>:<mainline>:30)␤ from gen/moar/stage2/NQPHLL.nqp:1289 (/home/camelia/rakudo-inst-1/share/nqp/lib/NQPHLL.moarvm:eval:190)␤ from gen/moar/stage2/NQPHLL.nqp:1492 (/home/camelia/ra…»
jnthn Aha
camelia nqp-moarvm: OUTPUT«MVMArray: atpos expected string register␤ at /tmp/tmpfile:1 (<ephemeral file>:<mainline>:30)␤ from gen/moar/stage2/NQPHLL.nqp:1289 (/home/camelia/rakudo-inst-1/share/nqp/lib/NQPHLL.moarvm:eval:190)␤ from gen/moar/stage2/NQPHLL.nqp:1492 (/home/camelia/ra…»
..nqp-jvm: OUTPUT«(signal ABRT)#␤# There is insufficient memory for the Java Runtime Environment to continue.␤# pthread_getattr_np␤# An error report file with more information is saved as:␤# /tmp/jvm-9508/hs_error.log␤»
..nqp-parrot: OUTPUT«Can't exec "./rakudo-inst/bin/nqp-p": No such file or directory at lib/EvalbotExecuter.pm line 188.␤exec (./rakudo-inst/bin/nqp-p /tmp/tmpfile) failed: No such file or directory␤Lost connection to server irc.freenode.org.␤»
rakudo-moar 48c0ba: OUTPUT«alive?␤»
jnthn will nqp-m next time :P 11:18
dalek arVM: da6e353 | (Jimmy Zhuo)++ | lib/MAST/Nodes.nqp:
small fix
 11:20
timotimo i've got a few local patches to cope with box + truthnesscheck and negation + truthnesscheck a bit better in spesh 12:03
jnthn Nice 12:04
timotimo but i have no good understanding of the &?ROUTINE thing yet 12:05
did you see that pretty much every code object now has a curcode + getcodeobj + bindlex_no for &?ROUTINE now? 12:06
well, not every code object of course
only for routines
jnthn yeah 12:08
I'm aware of that one
We got &?ROUTINE horribly broken beforehand, though.
timotimo right
i'm not saying "revert that patch stat!" ;)
jnthn :) 12:09
We can also elminate some cases of it in the Rakudo-level optimizer
timotimo i expected that, but i didn't really know what to look out for to prevent the elimination 12:10
i mean, i can guess we can search for QAST::Var that refer to the name and if none are there, we throw it out?
jnthn I think we rely on it being visible through CALLER is the thing 12:11
timotimo the good thing about the rakudo-level optimizer is that it can see directly into inner scopes, whereas spesh can not
yeah, i feared thta
that*
jnthn So we can eliminate it in simple ops
timotimo i remember being interested in building a simple analysis that stores "does this subroutine seem harmless?" information
like, does it access caller, does it eval, ...
and persist that across longer distances than our optimizer currently cares about 12:12
brrt \o 12:26
timotimo o/ brrt
jnthn The thing is "is it harmless" depends on the optimization 12:29
Which is why collecting facts about the code, then looking at them per transofrm we want to do, is the general approach I've been pushing it in
o/ brrt
timotimo right, it'd want some sort of flag vector 12:30
and also something that'll signal "the flags of this sub depend on the following subs that have not yet been fully analyzed:"
and then we have multi subs and other kinds of interesting things 12:31
brrt hmm 12:55
it turns out that the notion of a basic block within a tree is suspicious at best
jnthn Especially when the tree is a DAG? :) 12:56
brrt especially, as in my case, if the tree is really a DAG
yes
timotimo well, there's really the execution order tree/sequence and the data dependency graph/DAG 13:00
brrt hmm 13:01
actually
the linear order of the moarvm bytecode is fully preserved in constructing the expression 'tree' 13:02
and indeed postorder traversal generates just the same sequence 13:03
except for where a node is shared
as it is using the let statement
hmm
i'm wondering if the expr tree IR is not making me 'stuck' in a way 13:07
dalek arVM/even-moar-jit: 22bd3c0 | brrt++ | / (8 files):
Fix const operands

Not all literal operands are equally sized, so this patch differentiates between different consts. Also add a few new exprlist templates. These interact in known ways to make the pseudocompiler panic.		 13:15
timotimo :o 13:17
no newline at end of file
*gasp*
"interact in known ways to make the pseudocompiler panic" - that's somehow funny to me :)
brrt well... i can learn to live with it :-P
well, ehm, take a look at the template for sp_p6obind_o; because the write-barrier macro 'consumes' the second operand, it's no longer available for the second operation, becuase - being a conditional block - we can't properly rely on it being produced 13:19
timotimo oh 13:20
brrt i.e. the conditional block makes the load etc. conditional, but the nonconditional block doesn't recompute it because it assumes it should be there
assumption is the mother of all... 13:21
dalek arVM/improve_boxing_and_not: 21d34f0 | timotimo++ | / (7 files):
WIP on removing unnecessary boxing+unboxing

and deduplicate "not" instructions and such.		 14:39
timotimo pushed my WIP, will be on the road for an hour
timotimo i've got a test workload where the bigint boxing + unboxing optimization is hit, but it's only ever hit once and that's in prefix:<!> 16:21
i'll remove the debug output and see that spec tests are still happy 16:23
timotimo # expected: "1 9 25 49 81" 17:31
# got: " 1 9 25 49 81 "
i wonder how this happens
i know what part of my stuff causes this at least 17:34
what do i need to do so that it appears to me what's wrong ... i wonder 17:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!