hoelzro anyone still around? 00:26
I'm trying to debug this stupid issue, but it's proving...difficult.
timotimo oh hey 00:27
i wouldn't be much use, i bet
but i can be a rubber duck
hoelzro well 00:31
timotimo perf says the hottest instruction is atkey_o
hoelzro timotimo: do you remember the issue I was seeing this morning?
timotimo i don't think i do
segv on stack frames?
hoelzro yeah
timotimo ah, yes
hoelzro well, I thought it was a GC issue
which it still *could* be 00:32
if I log MVM_exception_backtrace and what it's putting into the annotations hash, it doesn't match up with the WHERE of $caller.file
which strikes me as odd
but I probably just don't understand Moar very well
timotimo i don't know how that part works either :( 00:33
hoelzro heh
then I'm in good company =)
timotimo i only know the part that goes "whoooosh" 00:34
hoelzro I like the whooosh
timotimo i bet you do :3
i have to say, moar is pretty cool. 00:35
hoelzro it is
timotimo i understand how parts of it work
hoelzro I think it's an important step forward
do you know if there's a function to create a copy of a string? =)
timotimo depends; do you want to copy the P6str or the MVMString that's contained inside? 00:36
diakopter can moar run on this www.tindie.com/products/bateske/arduboy/
hoelzro the MVMString
timotimo we don't copy those :P
let me has a look
hoelzro well, I had an idea about the callframe thing 00:37
I was thinking of copying the MVM string before setting it
timotimo i think we just refer to the same MVMString from multiple places
and then we have gc roots from locals, registers, ... that point at them
hoelzro I'm just wondering if, for some reason, these strings are being collected 00:40
timotimo i'd think these strings you'd be seeing are actually coming from a/the constant string pool or something 00:41
like, the filename has to come from somewhere 00:42
the string is probably allocated way earlier than the point you're looking at happens
if you have the address of the string, you ought to be able to figure out if it's in gen2 or the nursery
hoelzro that makes sense
timotimo actually, won't it have a flag set?
hoelzro doesn't know
the thing is 00:43
I don't know if it's a GC issue anymoar
timotimo mhm
hoelzro because I stubbed *out* the GC
and it still broke in the same way
timotimo oh wow :) 00:44
how well does moarvm handle not having a gc? :3
hoelzro well, it just keeps allocating memory =)
huh. 00:48
I think I fixed it!
hmm 00:49
well, I certainly prevented the segfault
but a far more insidious bug has now crept in
timotimo oh 00:50
yikes
well, i'm getting pretty sleepy 00:51
probably too sleepy to think straight anyway :)
good luck with your bug!
hoelzro thanks
and good night timo
TimToady \o here too :)
hoelzro night TimToady 00:52
TimToady no, I was saying night to timotimo++
hoelzro oh, ah ha =)
TimToady might have to go to dinner soon though :)
"too" because I just said o/ in #perl6 00:53
hoelzro ooo 00:54
it all makes sense now!
01:54 FROGGS__ joined 02:33 jnap joined 03:01 njmurphy joined 03:20 ventica joined 03:48 ventica2 joined 04:42 ventica joined 07:04 zakharyas joined 07:28 Ven joined 07:49 ventica2 joined 08:11 woosley left 08:25 brrt joined
brrt \o 08:26
nwc10 o/
FROGGS o7
brrt wow, radical
nwc10 brrt: All tests successful. 08:33
(spectests. With JIT. With ASAN)
for me 08:34
brrt awesome :-)
nwc10 ship it!
brrt no
nwc10 What I don't know is whether it's actually faster
joke alert!
it's like "negative setting parse time"
there was a silent smiley at the end
brrt there's somehow something that causes an infinite loop :-) 08:35
oh :-)
brrt may be overprotective of the project
nwc10 it's good that you care for it
brrt i've found another prove of Apple's Evilness 08:37
proof 08:43
FROGGS do tell
brrt basically, you know how apps can't use their javascript JIT compiler, but the browser (safari) can? 08:44
official reason is that the JIT compiler requires executable memory (correct), and this is a security liability (also correct) 08:45
but on the other hand, mobile safari does have JIT compiler support
now why would something be insecure for an app but not for a browser? that doesn't make any sense. 08:46
xiaomiao it's not evil when you earn money ;)
brrt apps can be checked before they ever get on users' devices; websites can load and run code coming from everywhere 08:47
if i had to put my money on the safest possible use of dynamic executable memory, it wouldn't be my web browser
xiaomiao apple also includes lots of weird stuff
brrt indeed :-)
xiaomiao remote tcp traffic logging? why would you expose that on a mobile device? 08:48
the only reason for that I can think of is industrial espionage
brrt that is weird indeed
08:48 tgt joined
brrt anyway, my point is that the real reason apple doesn't want JIT for javascript in their apps (or JITtted anything for that matter, although i wonder how they stand towards something like luajit) - is probably that they just don't want you to use javascript + html for apps at all 08:49
xiaomiao because then you could use the same app on android too!
tgt Apps will be able to use the faster JS engine in iOS 8. 08:50
brrt precisely
o really?
then my argument is invalid :-)
brrt brb 08:52
10:57 brrt joined 11:12 FROGGS[mobile] joined
brrt ok, so it's not eqat_s 11:18
and... it doesn't seem to be iter 11:25
brrt keeps on removing ops until it works 11:48
hmm 11:59
it seems now that moar-jit also loops forever 12:00
or, my configure is broken 12:08
ok, seems that was it 12:11
brb
12:30 brrt joined 12:40 jnap joined
nwc10 brrt: I have a suspicion that some of the makefile dependency rules are incomplete or wrong 12:48
I'm doing a full clean build each time, so I don't hit this
brrt such as?
nwc10 no great idea, but someone here or on #perl6 found that updating NQP and then doing "make install" didn't fail (when it should have) because the newer NQP source they had just updated to had bumped the Moar revision 12:49
the dependencies *are* correct from clean to build in parallel
or, the races are so rare I never hit them, even on 24 cores.
which is getting really unlikely
brrt the dependencies are correct, that i'm sure of; i think it moe likely i had misspelled my prefix 12:53
ok, the problem is iter 12:54
or iterkey_s
jnthn Getting iter wrong would be a pretty good way to infiloop :) 12:56
brrt i have a suspicion 12:57
but i'll have to check it 12:58
i suspect iter is throwish?
hmm, or that may not be it 13:01
i'll just see what the jit log says 13:04
what, i have isnull, why not isnonnull? 13:06
iter is used in quite a few places 13:10
how do you create a hash literal in nqp? 13:19
timotimo you don't; you always do nqp::hash( k, v, k, v, k, v ) 13:24
... right?
brrt ok, i'll try that then 13:25
moritz is {} always a block?
FROGGS yes, that is how you hash in nqp
moritz: {} is only a hash when it is empty
13:32 Ven joined
brrt obviously, if i try iter directly, it doesn't break 13:45
13:57 btyler joined
dalek arVM: e19695a | jimmy++ | src/io/dirops.c:
change to use instance->str_consts.empty
 14:17
14:39 jnap1 joined 15:04 woolfy joined 15:33 cognome joined 15:36 brrt joined 16:03 rurban joined 16:04 btyler_ joined, brrt joined 16:15 tgt_ joined 16:17 tgt joined 16:19 tgt_ joined 16:21 tgt joined 16:27 timo joined
flussence aha, finally got around to doing that moar bisect from yesterday. 16:30
(lot easier than I thought...)
anyway, ā€œf23408b0dcd221fe12e70e246dffe0ca35bc3424 is the first bad commitā€... 16:31
timotimo did commenting out my implementation of iter* not help the jit? 16:46
nwc10 brrt: the bad news - JIT is doing something undefined, hence SEGV in some cases. This is what valgrind makes of it: paste.scsys.co.uk/410729 16:58
jnthn back 18:01
18:05 brrt joined
nwc10 jnthn: as you might have already seen, that paste is a SEGV buildng the setting on Linux with JIT 18:06
jnthn Hmmmmm 18:07
nwc10 so it's demonstrably not all unicorns and rainbows yet
jnthn That's the one I got rid of on Windows by disabling an optimization
Also the one timotimo was seeing
So yeah, something very fishy
nwc10 OK, good, in that I can replicate what timotimo is seeing
brrt yes, very good indeed
i'll look at the code again
but it seems quite rare nevertheless? 18:08
nwc10 that's not "good" in the sense that I'm going to fix it. But that I can show that timotimo is not special
brrt or do you have this always
nwc10 repeatably for the compiler flags I'm using
with or without --optimize
brrt which are?
nwc10 perl Configure.pl --prefix=/home/nicholas/Sandpit/moar-g-jit --enable-jit --cc=ccache\ /usr/local/gcc49/bin/gcc --ld=/usr/local/gcc49/bin/gcc --debug --optimize=0
brrt it isn't bad, because there's only a single place this ever gets called 18:09
oh, thats gcc49
hmmm
but timo saw it with gcc48 already
nwc10 gcc (GCC) 4.9.0
brrt oh, i see
*ahem* 18:10
nwc10 same gcc building with ASAN does not go SEGV. So I
brrt now wonders how this ever even worked
nwc10 I'm guessing that the ASAN flags end up doing something different to the code gen
brrt wait, i'll show you the line, and you'll see what's wrong
nwc10 I think I'm stating the obvious here :-/ 18:11
OK
brrt github.com/MoarVM/MoarVM/blob/moar...dasc#L1169
first one to spot the error gets a 100 kudos 18:12
nwc10 well, I can't, because I don't know the ABI. (I don't know x86_64 assembler, but I can guess it)
aha, but if the commentis correct, then the arguments are transposed 18:13
brrt it's in the comment, in fact
well, yes :-)
i /used/ to push TMP6 (the callsite pointer) to the stack, leaving rsp being the address of tmp6
nwc10 oh, no, I can't guess assembler enough - I don't know which is source and which is dest
but comment has [] and code does not 18:14
brrt but, i don't push anymore since that makes keepking the call stack properly aligned challing
nwc10 so code is loading a register, but it's supposed to be writing to memory addressed by that register?
brrt the first is the destination, the second is the source
well, no, &cur_callsite is the pointer to the top of the stack, which is rarely if ever assigned to anything
i.e. i pass 4 arguments to find_invokee_multi_ok, namely threadcontext, the code object (which i only then load from the work register) , &cur_callsite, args 18:15
but &cur_callsite /used/ to be top of the stack, since i used to push it 3 instructions earlier 18:16
so setting arg3 = rsp (top of stack) was ok, but i don't do that anymore, since that ultimately causes stack-walking, and that causes callee-save-register gibberish, and that ultimately causes a crash 18:17
nwc10 "can you fix it?" 18:19
brrt :-)
i'm testing a fix now
brrt finds it still amazing that this ever used to work and that jnthn++'s patch did anything 18:20
nwc10 it's scary how much buggy code doesn't crash early enough
jnthn Wow
brrt++
And nwc10++ for finding it, of course 18:23
brrt concurs with nwc10
nwc10++ indeed
nwc10 I didn't find the fix. Just got tools to produce a plausible backtrace 18:24
brrt and timotimo++ for insisting, by the way
nwc10 *now* can we ship it? :-)
brrt suspects my processor may have been doing something really funky that hid the crash
dalek MoarVM/moar-jit: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files): 18:26
MoarVM/moar-jit: cur_callsite is no longer top of stack
MoarVM/moar-jit:
MoarVM/moar-jit: MVM_frame_find_invokee_multi_ok expects to take the
MoarVM/moar-jit: address of the current callsite. I used to push the
MoarVM/moar-jit: pointer to this object on the stack, so that the stack
MoarVM/moar-jit: pointer was in fact the address of this object. However,
MoarVM/moar-jit: I don't use push and pop anymore, instead using a statically
MoarVM/moar-jit: allocated stack frame of 96 bytes large. Since this
MoarVM/moar-jit: means the cur_callsite pointer is stored somewhere else, the 18:27
MoarVM/moar-jit: 3rd argument is gibberish. Fix by loading the current location
MoarVM/moar-jit: into the 3rd argument.
MoarVM/moar-jit:
MoarVM/moar-jit: nwc10++ and timotimo++ for getting good backtraces.
brrt i just keep on making dumb mistakes so i can reap the rewards of fixing them :-)
timotimo ooooh
dalek MoarVM/jit-moar-ops: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files): 18:28
MoarVM/jit-moar-ops: cur_callsite is no longer top of stack
MoarVM/jit-moar-ops:
MoarVM/jit-moar-ops: MVM_frame_find_invokee_multi_ok expects to take the
MoarVM/jit-moar-ops: address of the current callsite. I used to push the
MoarVM/jit-moar-ops: pointer to this object on the stack, so that the stack
MoarVM/jit-moar-ops: pointer was in fact the address of this object. However,
MoarVM/jit-moar-ops: I don't use push and pop anymore, instead using a statically
MoarVM/jit-moar-ops: allocated stack frame of 96 bytes large. Since this
MoarVM/jit-moar-ops: means the cur_callsite pointer is stored somewhere else, the
MoarVM/jit-moar-ops: 3rd argument is gibberish. Fix by loading the current location
MoarVM/jit-moar-ops: into the 3rd argument.
MoarVM/jit-moar-ops:
MoarVM/jit-moar-ops: nwc10++ and timotimo++ for getting good backtraces.
brrt please check if this fixes it for you timotimo :-)
and nwc10 as well
timotimo will do 18:29
brrt still hangs on nqp building, unfortunately 18:35
timotimo yes, it does :( 18:37
hangs in grammar.nqp, too 18:41
nwc10 brrt: through the rakudo sanity tests and into the spectests 18:45
timotimo and in stage parse, too
brrt \o/
yes, i know
timotimo good to know :)
AFK, food
brrt brb 18:47
nwc10 All tests successful. 18:48
Files=908, Tests=31963, 199 wallclock secs (14.95 usr 3.85 sys + 3477.11 cusr 173.58 csys = 3669.49 CPU)
Result: PASS
jnthn That's a fast box :) 18:51
nwc10 it's fastest when it has 24 things to do in parallel 18:52
jnthn Oh :)
"Core blimey"
nwc10 the future is multicore
which, as my daughter likes to say "I know that already" 18:53
18:54 brrt joined, btyler joined
nwc10 re-running the setting build under valgrind is not the fastest 18:55
22076 nicholas 20 0 497m 423m 11m R 100.0 0.4 7:00.44 memcheck-amd64-
19:02 Ven joined
brrt nqp testsuite interestingly enough burns in jit-moar-ops with /only/ iter 19:02
and without, it seems 19:06
:-o only two weeks left or so 19:12
FROGGS PANIC
brrt and no support for extops yet 19:17
ok, no panic 19:18
nwc10: you're sure the sanity test runs for you? 19:19
nwc10 All tests successful.
Files=22, Tests=271, 3 wallclock secs ( 0.14 usr 0.03 sys + 35.62 cusr 2.23 csys = 38.02 CPU)
Result: PASS
yes, for me
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22076 nicholas 20 0 1101m 1.0g 11m R 100.0 1.1 31:40.82 memcheck-amd64- 19:20
brrt hmmm
nwc10 no, I don't know why I get lucky 19:22
Stage parse : 2062.728 19:25
OK, so progress
so, expect about 240 seconds for stage optimize and 800 for mast 19:27
Stage optimize : 227.126
OK, 800 more before it finishes
brrt ok, moar-jit proper also runs testsuite fine 19:31
(for me)
nwc10 22076 nicholas 20 0 1414m 1.3g 11m R 99.7 1.4 47:09.09 memcheck-amd64- 19:35
still chugging. probably 5 more minutes 19:36
22076 nicholas 20 0 1545m 1.4g 11m R 99.6 1.5 52:01.54 memcheck-amd64- 19:40
and done
so, yes, I can build the setting with the JIT under valgrind. But it takes a while 19:41
==22076== in use at exit: 808,365,911 bytes in 2,627,380 blocks
==22076== total heap usage: 21,434,309 allocs, 18,806,929 frees, 12,397,083,759 bytes allocated
jnthn So allocation... 19:43
nwc10 "so allocation, very churn, sigh" ?
jnthn yeah
Though I know one source I can elimiante easy enough.
nwc10 exterminate! extermiate!
timotimo i'd be interested to know where that is 19:44
we could perhaps just keep blocks used for spesh around
no need to free the memory if we end up speshing something else a few miliseconds later ...
jnthn I don't think spesh is the big cause 19:45
I was more thinking the NFA
timotimo oh 19:46
right, they have to allocate, too
jnthn Yeah 19:47
But a given thread can only be evaluating one NFA at a time
timotimo and we run lots and lots and lots and lots of nfa 19:48
jnthn So we can just keep the memory around hung off le tc
nwc10 please be keeping an option to disable this, so that we don't do a heartblead
timotimo hmm, nfas will only leak data very indirectly
nwc10 yes, I was really joking about the seriousness 19:49
timotimo as in you can only really gleam what text was being matched if you get a dump of the nfa storage
nwc10 but the unerlying thing is that it's useful to be able to disable a custom allocator, to enable the use of memory sanitsing tools
jnthn nwc10: In this case we're not allocating multiple different things in the block, just keeping a block around for next time. So it's less of an issue than, say, the fixed size allocator, which really does need a disable switch. 19:50
timotimo btw, there's a gcc attribute for "this function is malloc-like" 19:55
19:57 colomon joined
nwc10 JIT ASAN spectest PASS. 20:04
now, back to the thing I was actally trying, which caused the bug hunt - optimised JIT build 20:05
oooh, t/spec/S32-io/IO-Socket-Async.rakudo.moar failed for me on the re-run 20:10
not ok 4 - Echo server
nwc10 asks everyone to imagine the blank line here
# Failed test 'Echo server'
# at lib/Test.pm line 75
FROGGS master also does
nwc10 it flaps
but it rarely fails on a re-run 20:11
FROGGS you were lucky :o)
nwc10 anway, optimised JIT build passes 20:13
flussence goes file a proper bug report for this thing that's been bugging me 20:22
hoelzro flussence: what's that?
flussence since moar f23408b0, one of my modules dies after *exactly* 17/50 tests with the error @ src/gc/collect.c l421 20:23
hoelzro flussence: any useful output from the test? 20:24
like a segfault or something?
jnthn The error there is basically saying "if we go on we're gonna SEGV" 20:25
flussence no other output, just "Internal error: zeroed target thread ID in work pass" and it abruptly exits... jnthn is right though, I was poking at it in gdb and the next thing that would've happened is a null pointer deref.
...aaaaand it works in current rakudo head... oh well. 20:26
jnthn Hm 20:27
timotimo d'oh 20:28
hoelzro ok, different from my error 20:31
20:31 brrt joined
hoelzro which has been really hard to figure out 20:31
flussence hm, I might've been using a stale install and it may not actually be fixed... one sec 20:37
brrt timotimo: wrt to your plans to write a jit log analyser, i'm planning to refactor that code a bit (so less analysis may be needed) 20:39
timotimo that sounds good 20:42
so, did we figure out that iter is not to blame for our hanging problems?
brrt good news btw 20:45
well, it is to 'blame' somehow, but not in the way you'd typically think of it
it's probably not broken but it allows brokennes, is what i mean
anyway, good news again, i've singled out a failing spectest that fails with iter (but not without) 20:46
timotimo great!
flussence well I'm confused... I get that MVM_panic message if I try running my p6 code under gdb but it works fine normally. 20:51
I guess as long as it works well enough I can get on with doing stuff, so that's good. :) 20:52
timotimo brrt: when that bug is found and fixed, what's next on your roadmap? :) 20:56
brrt uh...
well....
:-)
timotimo sp_findmeth seems to be at the top of the bail list by far
brrt extops
timotimo mhm
brrt yes, that's a big one
ok, sp_findmeth before that
:-) 20:57
timotimo do you think lt/gt/eq/ne _n and not_i would be quickly doable, too? :3
jnthn I hate to throw this one in, but jumptable will also be rather critical-path 20:58
timotimo moarvm has jumptables?
jnthn Sure
Used in every single regex/rule/token. :)
timotimo ah, is that for the nfa? 20:59
like, the result of the nfa gives us the index into a jumptable?
jnthn No
Well
Yes for alts
timotimo would it be enough to implement "die" as a call to the right function to make it throw correctly, or does it need special treatment to work with the jit and stuff?
jnthn But more generally it's used for the backtrack stack
timotimo ah, good
jnthn Well, it's a throwy operation
In other news, I'll have Fri/Sat/Sun for Perl 6 things. :) 21:00
timotimo \o/
getattr_o seems to be hot, too. i can probably implement that esaily-ish 21:02
brrt yes, num comparisons are conceptually simple 21:03
\o/
although i have fri/sat/sun for social things, but i'll try to be there 21:04
well... how hard is jumptable, really?
also, i do in fact think that throwy operations need quite a bit more work 21:05
but i've been in bughunt mode so long now
jnthn brrt: Doin't expect jumptable will be that hard. It's what it says. 21:06
brrt: In the worst case you can spit out an if ladder :P
brrt that's true
but, all jumptable exits are basic blocks, right? 21:07
then they already have a label
jnthn Yeah
brrt ok, then i'm not too afraid of it 21:08
:-)
then it's 'just a branch'
timotimo aaw, there is no bindattr to copy code from 21:12
i hope the getattr code is copyable :P
brrt i suppose it is, as long as you ensure proper guards are in place :-) 21:13
jnthn If you mean wbs then I think they're all in the reprconv.c function 21:14
And bindattr canny invoke
So not sure what guards are needed...unless I'm forgetting something :)
brrt well, yeah, these are what i mean :-) 21:16
write barriers
jnthn k
brrt and yes, feel free to work further so long as i'm still trying to squash our current one
(and unearth more bugs at the same time :-))
[Coke] oh. I wonder if I can incorporate the rakudo-jvm-in-eclipse work to run perl6 from coldfusion. 21:19
ww
jnthn #moarvm loves Rakudo JVM too :) 21:20
21:22 Ven joined
dalek arVM: 5df280f | jnthn++ | src/ (2 files):
Avoid repeatedly allocating memory for NFAs.
 21:26
timotimo bindattr can invoke? 21:28
i thought repr ops never invoke? 21:29
jnthn timotimo: no, it can't
And you're right, they don't
timotimo ah, so canny == cannot :)
jnthn yes :)
timotimo okeh
jnthn ETOOSLANG
m: say 790566 * 7 * 8 21:39
camelia rakudo-moar c00999: OUTPUTĀ«44271696ā¤Ā»
jnthn m: say (790566 * 7 * 8) / 4194304
camelia rakudo-moar c00999: OUTPUTĀ«10.5551949ā¤Ā»
jnthn Hmm. This might be a nice win... 21:42
brrt oh, i think i've found something truly nasty 21:43
jnthn brrt: Uh-oh...what?
btw, above calcs relate to alternations. We currently build the labels array every alternation, even though it's static information. Which was expedient when doing the initial code gen, but now accounts for 10 GC runs while building CORE.setting. 21:44
brrt well, the qregex bug, right?
jnthn brrt: Is that the iter one?
brrt it seems it only appears when nqp was /built/ using the iter
it seems so
but let me check again
jnthn Ah, so somehow the iter causes a mis-code-gen? 21:45
Got a link for me to the patch that added iter and related ops to the JIT?
brrt uhm, yeah, i suppose 21:47
this one did, but it's nothing funky as far as i can see 21:48
timotimo now i have a single function that covers bindattr_i, _n, _s and _o 21:50
yay
jnthn "this one"? :) 21:51
brrt oh, sorry :-) 21:56
TimToady "that one" :) 21:57
brrt github.com/MoarVM/MoarVM/commit/d2...d963b749a0
what does nqp::getcodename doe? 21:59
do?
jnthn Gets the name of a code object 22:00
timotimo with an implementation of the bindattr ops NQPHLL and NQPP6Regex both hang
brrt do you have iter? 22:01
other way to phrase that question
do they still hang when removing iter? 22:02
brrt can't get the hang of this weird iter bug 22:05
jnthn Why are iterkey_s and iter handled differently in the code-gen from iterval, when the code-gen looks the same? 22:06
22:07 lizmat joined
brrt no reason 22:07
all of these can be collapsed into one for all i care
also, fwiw, register indices are 16 bits wide 22:09
timotimo er, huh? 22:13
no, iterkey_s returns a string, iter and iterkey return obj
that's the difference
oh
but ptr is str 22:14
so they *are* the same
oops :)
without iter and friends nqp gets through the build completely 22:18
seems like so does rakudo 22:20
aye.
wow, 96 bails from islist 22:26
when do we generate that code %)
jnthn brrt: One thing that occurs to me 22:27
brrt: Iterators use boolification to see if we're at the end
brrt: I don't suppose there's any chance we could be looking at an istrue bug in disguise?
timotimo brrt: indexat and indexnat are both branchy, but indexat only happens 42 times in core setting now ... 22:28
dalek arVM/jit-moar-ops: 18c6ecb | (Timo Paulssen)++ | src/ (3 files):
support bindattr_inso
timotimo and indexnat happens even less often 22:29
dalek arVM/jit-moar-ops: 9f86dda | (Timo Paulssen)++ | src/ (3 files):
implement all the getattr ops: inso.
 22:50
timotimo hunts the jit log some more
flussence oh, things are getting interesting. I just built everything from master and that GC bug I was getting before is now a segfault *sometimes*. 22:51
gist.github.com/flussence/0eeb33d93f24946b8ca8 now with actual gdb backtrace :D 22:52
brrt jnthn, i agree, but tbh... i find that rather unlikely given that boolification is already used extensively 22:54
anyway, i'm of for tonight 22:55
22:55 brrt left
jnthn 'night, brrt 22:55
timotimo gnite jnthn 22:56
gnite brrt
why does newlexotic cur_op += 6? does it have some storage next to it or something? 23:02
jnthn It's a reg + a 32-bit offset iirc
timotimo oh? 23:03
it uses GET_UI32(cur_op, 2)
so ... i'm confused
oh, that's 32bit ... duh 23:04
it must be late ... 23:06
FROGGS it is 23:09
23:17 ashleydev joined
timotimo tomorrow i'd like to know if i can safely ignore the if (ctx->callsite->num_pos != ctx->callsite->arg_count) that is part of paramnamesused (because we've spesh'd this callsite already) 23:22
23:32 ashleydev joined
dalek arVM/jit-moar-ops: eb19462 | (Timo Paulssen)++ | src/jit/graph.c:
implement newlexotic
 23:42
arVM/jit-moar-ops: 5ab4b4b | (Timo Paulssen)++ | src/ (3 files):
setelemspos for le jit
arVM/jit-moar-ops: 4cae0f9 | (Timo Paulssen)++ | src/jit/graph.c:
iter, iterval and iterkey make stuff hang in compilation :(
timotimo gist.github.com/timo/f92ff69eb404592b3a51 23:43
about 1150 frames we couldn't jit 23:44
hmm. had i put the bail log into a git after implementing each op, we could have fun stats to look at 23:46
gist.github.com/timo/f92ff69eb4045.../revisions 23:48
"32 bindpos_i turned into 10 sp_findmeth, 20 islist, 1 indexat, 1 iscclass" 23:49

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!