01:30 FROGGS joined 02:14 btyler joined 04:08 btyler joined
tadzik g'night 07:51
FROGGS gnight? 07:52
don't tell me you are in Old Europe™ and still awake since yesterday :o) 07:53
nwc10 I hate all operating systems. Drink!
FROGGS nwc10: I only hate openbsd atm
nwc10 I'm only trying to get sane answers from uname 07:57
FROGGS and I only want to load a dynamic library :/ 08:04
nwc10 could you tell me the output of uname -m and uname -p on OpenBSD? 08:12
FROGGS sure... hold on 08:13
both is either amd64 or i386 08:15
tested on openbsd 5.4 and 5.5
nwc10 just to check, both uname -m and uname -p return 'amd64' on th x86_64 machine? 08:16
FROGGS exactly
nwc10 thanks. that's consistent with FreeBSD, but not NetBSD 08:17
on NetBSD, uname -m is amd64, uname -p is x86_64, on the machine I have access to
FROGGS starts his NetBSD 5.1.3 08:23
ohh, that is only i386 and both -m and -p report that 08:24
08:29 flussence joined, _sri joined
FROGGS nwc10: I've got something for you :o) 08:34
uname -a # OpenBSD openbsd47.localdomain 4.7 GENERIC#558 i386
uname -m # i386
uname -p # Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz ("GenuineIntel" 686-class)
nwc10 thanks. I'd elected to go for -m on *BSD 08:37
that's insane 08:38
actually, maybe it's technically not insane
lizmat
.oO( sanity is in the eye of the beholder )
 08:44
FROGGS ~> uname -a # Haiku shredder 1 42211 Jun 18 2011 08:26:42 BePC Haiku 08:59
~> uname -m # BePC
~> uname -p # unknown
though, I don't think that matters much :o)
nwc10 does libuv work on Haiku yet?
FROGGS I have no idea
nwc10 Me neither, but I'm going to guess no
FROGGS that is a good bet I think... 09:00
I'll set up smokers once we have a place we can send reports to (cpantesters)
nwc10 smokers would be really useful 09:02
FROGGS yeah... 09:03
I mean, colomon++ does that, but only he sees the results
imagine you'd only smoke P5's module tests right before a (dev-)release... that'd be insane :o) 09:04
though, normal for us :(
I hope ANDK++ has time for me this weekend, because the indexer is the very first thing that needs to work 09:05
lizmat FROGGS: why would we need CPAN's indexer for Perl 6 modules again? 09:17
FROGGS lizmat: to have a list of dists for panda to choose from
and to have proper release we can smoke
releases*
lizmat so a de-factor recommendation manager ? 09:18
*de-facto
FROGGS no
there is no recommendation yet
lizmat ok, just listing
FROGGS there can only be recommendations on like 10 Foos when we have a list of Foos 09:19
lizmat indeed
ok :-)
FROGGS so that would be a step after we have our p6-modules.json
or p6-dists.json or what it is called 09:20
lizmat indeed....
FROGGS and for the meantime panda would ask the user to choose the Foo from a list of auths until we have the recommendations 09:22
and this meantime can happily last a year without anybody complaining I think
lizmat yup 09:24
FROGGS++
FROGGS but having proper releases and test results would be like quality**gazillian
I pinged ANDK a minute ago... hopefully he can have a look at my proposal for 3 database tables and the jobs that create json blobs (for panda) 09:26
nwc10 lizmat: 09:27
lizmat: are you able to build Rakudo on MoarVM on OS X?
lizmat yes, I *only* do MoarVM lately
nwc10 OK, odd, I get a SEGV 09:28
#0 0x00000001015f8a44 in p6captureouters () from /Volumes/Stuff/Perl/rakudo/dynext/libperl6_ops_moar.dylib
lizmat is this about "make install" ?
nwc10 during setting compilation
too much ohter stuff going on, so not going to try to debug that
as
a) I don't seem to have debugging symbols
b) I have no good idea how to bisect MoarVM/NQP/Rakudo 09:29
lizmat neither :( 09:30
09:36 flussence joined, _sri joined
tadzik aaargh :| 09:38
is there a way to turn off spesh with an arg or so?
or an env var?
oh, nevermind 09:39
FROGGS env, yeah :o) 09:45
tadzik how do you do that? 09:46
FROGGS tadzik: MVM_SPESH_DISABLE=1 09:47
tadzik thanks :)
jnthn tadzik: You're not meant to be able to notice the difference besides a performance boost. What's happening? 09:55
tadzik jnthn: you said yesterday that you found the transformation which causes the nativecall bug
so I thought if I turn it off I can continue development :)
I read "transformation" as "spesh magic"
jnthn tadzik: Oh, no...I was working on the bug in the spesh_trace branch. Sorry for confusion. 10:01
tadzik ah
jnthn aww crap 10:53
I think I may know what's going on 10:54
ah, no... 10:55
grr 10:57
11:05 flussence joined, _sri joined
jnthn oh hmmm 11:40
It's something to do with deopt.
Of note, deopt_all
FROGGS jnthn: I am doing this now in _is_same_label, and it seems to work :o) tc.curFrame.curHandler = outerHandler 11:46
right before emitting the throw
jnthn ooh 11:48
Yeah
That...uh...might just be a hack, but. :)
FROGGS jnthn: well, that is what delimit_handler does, so...
and I can't move my stuff to delimit_handler because it needs to stay in catch 11:49
jnthn FROGGS: OK, let's go with it provided it doesn't cause any other fallout. 11:57
Meanwhile, I think I may have an idea what's going on with the deopt issue.
jnthn spent all last night's searching not knowing it was a deopt issue :/
FROGGS yeah, I will test nqp, then build rakudo on top of that and spectest it, before I try to get labels into perl6-j 11:58
jnthn: yeah, I've seen your messages :/
jnthn And it looks like it might be a one line addition to fix it. 12:04
This'll go down as the longest one-line patch in a while.
FROGGS *g* 12:05
dalek arVM/spesh_trace: 6a2a829 | jnthn++ | src/spesh/deopt.c:
Don't deopt frames that are just logging.

They didn't make any assumptions that could be broken, and this just prevents us logging as much as we might.		 12:14
arVM/spesh_trace: f57f1ea | jnthn++ | src/spesh/manipulate.c:
Don't lose deopt annotations when deleting sp_log.
MoarVM/spesh_trace: e0b3806 | jnthn++ | src/spesh/codegen.c:
MoarVM/spesh_trace: Pre-invalidate all deopt target addresses.
MoarVM/spesh_trace:
MoarVM/spesh_trace: This prevents us accidentally having them match up. This can happen if
MoarVM/spesh_trace: we set them when producing the logging bytecode, but then toss chunks
jnthn Much of the reason it was hard to find was that deopt basically ended up putting the interpreter at an arbitrary instruction 12:15
But a valid one, still.
vendethiel dalekd died through ?
jnthn But having it do so required an offset in the logging bytecode to align with an offset in the optimized bytecode 12:16
So the bug was actually nothing to do with the particular transformation that I narrowed it down to
It's just that making that transformation caused the two sets of bytecode to align in such a way that we hit the now-bogus deopt table entry. 12:17
It's also a fairly extreme action at a distance: the deopt was triggered about 20 frames deeper than the pblock call that got deoptimized, meaning it was a long, long time until we ended up back in it again. 12:18
Anyway, I think I'll find something to eat, and then will look at the other opts I was wanting to work on, now the bug is out of the way... 12:20
FROGGS jnthn++
dalek arVM/loop_labels: d6a554f | (Timo Paulssen)++ | src/spesh/facts.h:
remove duplicate words from from comments
 12:27
arVM/loop_labels: 26ecc5d | (Tobias Leich)++ | src/spesh/facts.h:
Merge branch 'master' of github.com:MoarVM/MoarVM into loop_labels
timotimo it seems like i can now build a moarvm with -O3 and now i'm trying to add -flto to that 14:08
14:09 benabik joined
jnthn Well, building a MoarVM with -O3 ain't the issue; it's building everything else atop of it that's been problematic... 14:10
timotimo i know
i'm in the setttings compilation right now
used to blow up much earlier, iirc
jnthn ooh 14:17
retupmoca jnthn: github.com/MoarVM/MoarVM/pull/95 doesn't seem to break anything, and it fixes a precomp issue with File::Find::Duplicates 14:40
(and possibly others)
if it looks sane, I'll add the WB to jvm as well
jnthn retupmoca: That seems...odd 14:47
I mean, in theory that's a no-op... 14:48
retupmoca before I put that in, I was getting "No object at index 469" after precomp 14:55
FROGGS retupmoca: can you comment it out and try again? perhaps applying this fix had side effects... 14:57
jnthn Hm, it looks a bit like something is just shoving an object into an SC regardless of if it already lives in one. 14:59
I think making scsetobj explode if the object you're trying to set an SC on is already in one may be a better route 15:00
And then find out which bit of code is doing that.
And fix it to be more careful.
retupmoca ok 15:01
is there an easy way to do that lookup? 15:05
it looks like MVM_sc_set_object doesn't touch the object at all, it just stores a pointer to it in the sc 15:06
jnthn MVM_sc_get_obj_sc(tc, obj)
Yeah, actually the issue is if it adds an object that already belongs to another C
*SC
I mean, I can see now why the WB helps 15:07
But still it seems like something, somewhere, is being careless
timotimo an overwhelming amount of ok-ing spectests with -O3 -flto
jnthn Sounds promising 15:09
jnthn wonders if it's faster
timotimo gist.github.com/timo/29ad10576efde56946cf - these are the results 15:10
the timing is probably not very precise, as i've been using the computer for other things, too
jnthn yeah...a p6bench run is probably more indicative. 15:13
timotimo one where i don't run other things ;)
FROGGS hmmm, that S02 and S12 is weird... 15:14
timotimo probably the is rw things that happened
FROGGS the rest is kinda expected
timotimo it's not a fresh rakudo checkout
FROGGS ahh, okay
retupmoca jnthn: ignore my PR - I think it was just some kind of corruption in my local environment 15:31
since it seems to be OK now
dalek arVM/spesh_trace: bc8c6c7 | jnthn++ | src/spesh/optimize.c:
Add call opt infrastructe; optimize simple calls.

This adds callsite and args tracking, and optimization of single dispatch cases when we know where we're going at specialize time. In this case, we can extract the code object from its HLL wrapper at spesh time rather than per call, which will be a slight saving.		 15:41
arVM/spesh_trace: 5cc5349 | jnthn++ | src/spesh/optimize.c:
Add statically resolved method to facts.

This means that its visible to the various invocation optimizations.		 15:42
16:37 flussence joined, _sri joined
dalek arVM/spesh_trace: 6766b91 | jnthn++ | src/spesh/optimize.c:
Store facts for compile-time-resolved lexicals.

Enables other optimizations to apply.		 16:41
arVM/spesh_trace: 0ad1bb0 | jnthn++ | src/ (5 files):
Resolve multi-dispatch at spesh time if possible.
jnthn m: say 5.05 / 5.84
camelia rakudo-moar c5ac80: OUTPUT«0.864726␤»
nwc10 this is a good number? 16:44
jnthn Well, it means spesh now makes a given benchmark run in 86% of the time it takes without it. 16:45
nwc10 that would be a good thing? :-) 16:49
OK, so if I try to malloc() and copy the bytecode, as a proof of concept for Big Endian games 16:50
I fall foul of a check at line 226 of frame.c:
outer->static_info->body.bytecode == static_frame_body->outer->body.bytecode
because I've cheated, and replaced body.bytecode with my copy
jnthn Ah
Yeah, it's using bytecode as an identity check there...
16:50 zakharyas joined
nwc10 I'm wondering if I should simply add a second pointer, one is the original, one is the possible copy 16:51
the original is the identity check
jnthn That was what I was about to suggest.
nwc10 and if they differ, that's the signal to free the other one
jnthn +1
nwc10 OK, by the magic of git, I'm going to fix up my previous commit, which put an enum for NOOP/free/munmap in moar.h 16:52
which clearly doesn't need to be anywhere as common now
as it's only going to be in one place now
not the two I had thought
much rattling from swap
there was this nice five minutes when it was very quiet
and about 98% CPU was user 16:53
but that time has passed
jnthn wonders if simple OSR would really be so hard to implement... 16:54
nwc10 OSR?
jnthn On Stack Replacement
Basically, noticing the current frame is a hot loop and replacing the bytecode with an optimized version of itself 16:55
nwc10 thanks for the reminder. You'd told me, and I'd forgotten 17:11
glossary time?
also, I like ASAN. It's fast enough to use as the default dev build
and it blows up spectacularly early for a bunch of PEBKAC errors 17:12
17:17 brrt joined 17:27 btyler joined
nwc10 jnthn: is the MOARVM stream 2 byte aligned? Or 1? 17:39
In that MVM_operand_int8 suggests that it's 1
jnthn There's nothing smaller than a short in it. 17:41
Don't think MVM_operand_int8 is used anywhere; it's more intended for putting on a local 17:42
Hm, there's one single mention of int8 in oplist
On an op I'm sure we dont' use
17:42 btyler_ joined
nwc10 const_i8? 17:42
jnthn Yeah
nwc10 unimplemented
jnthn And if we do implement it, I'm happy enough to say that it must be emitted with a padding byte 17:43
So in answer, yes it's 2-byte aligned, and yes we can keep it that way for the long term. 17:44
timotimo has somebody already volunteered to implement the "automatically use smaller integer constant instructions if available" stuff? 17:46
17:46 brrt joined
jnthn Not yet 17:46
nwc10 timotimo: I didn't. I noticed it, but decided that I'd rather do some other stuff
jnthn Also we need a const_i64 variant that loads into a 64-bit register, but reads a 16-bit or 32-bit number to do it. 17:47
nwc10 jnthn: I looked at the interp.c code and thought "mmm, blocks inside switch blocks. Ugly, but must be legal, because of Duff's Device" 17:48
as in, we're not doing it, but we'd avoid code duplication with that bit of local ugly
timotimo jnthn: these would be different opcodes altogether, aye? 17:51
jnthn timotimo: aye 17:57
timotimo that side of the implementation seems rather simple 17:58
nwc10 Stage mast : 19777.336
timotimo did we decide on where the decision to put one of these instructions should be made?
nwc10 Stage mbc : 405.653
a setting is mine. All mine
jnthn \o/ 17:59
timotimo: I think in src/mast/compiler.c 18:00
nwc10 jnthn: nothing actually calls unread_op() in validation.c currently
jnthn nwc10: yay!
nwc10 I put in abort() in it
jnthn OK :)
dinner, bbiab
flussence nwc10++ # amazing patience
nwc10 flussence: oh, well, the trick was to lie in the hammock, walk the dogs, and a bunch of other things 18:01
including hack on something else
18:06 brrt left
timotimo jnthn: what branch should i base my stuff off of? 18:07
(since i'll be adding opcodes) 18:08
jnthn: if i implement this, we can push the stage0 update for nqp-m a bit further and have smaller constant integers all over :) 18:11
jnthn: do we ever use 32bit integer registers, btw? 18:13
apparently only in the extend ops :P
jnthn Not yet, but we don't support int8, int16, etc lexicals yet 18:27
timotimo ah
are const_i8_64 through const_i32_64 acceptable names? 18:28
or should i swap the numbers?
jnthn keep prefix as const_i64 18:29
timotimo OK
jnthn keep prefix as const_i64_16, const_i64_32 work for me
FROGGS .oO( const_i64_XXXII ) 18:30
timotimo :D
FROGGS 64 would be MXIV?
jnthn wtf... :) 18:31
FROGGS I think it was <I V M C L ...> but not sure :P
timotimo and GET_I32(cur_op, 2) and friends should work, right? 18:32
jnthn aye
timotimo ok, and the 8 variant will += 3, the 16 will += 4 and the 32 will += 6?
jnthn Uh, we don't want an 8 variant 18:33
timotimo oh, ok
jnthn Since the bytecode stream is 16-bit aligned anyway
timotimo ah!
of course.
jnthn ooh, I see patches
timotimo we could have a "load these two 8 bit integers into the register and its next register :P
nwc10 jnthn: you got a bcc on the most recent message as it's not sent from the usual place, and I don't know if that will spook the list moderation 18:34
timotimo oooh, or an 8bit number and a shift :D
nwc10 the usual place has been down for 8 hours
timotimo jnthn: src/mast/compiler.c doesn't know anything about the const_i64 operation itself; i'm not sure if special-casing it would be a good choice 18:38
in theory it could go here: github.com/MoarVM/MoarVM/blob/mast...ler.c#L566 18:46
jnthn timotimo: oh, I think it'll have to be a special case on that instruction. 18:48
timotimo oh, i ought to have looked a bit lower down there
jnthn Well, I think you're in about the right place
timotimo the constants are not ops :) 18:49
oh, wrong again
jnthn const_i64 is an op 18:50
timotimo yup 18:52
i thought i saw an if istype "local"
but it was really "label"
19:07 flussence joined, _sri joined
timotimo jnthn: would you rather i factor out the "write a 16 or 32 bit integer operand to the stream" and re-use that or manipulate the operation before writing it out? 19:12
jnthn timotimo: Manipulating the operation is probably evil 19:22
timotimo aye 19:24
is ((MVMint32) iv->value == iv->value) good enough? 19:27
19:32 flussence joined, _sri joined
timotimo the code i'm writing right now is properly terrible 19:36
Error while compiling op ifnull (source text: "nqp::ifnull($!nominal, 0)"): P6opaque: no such attribute '$!result_reg' 19:44
how did i get that error o_O
TimToady just as long as it's not terribly proper
timotimo ah 19:45
the error is there even without my modifications
so that's a good start
jnthn timotimo: That sounds like you're working on spesh_trace and didn't update your NQP to use the lexopt branch 19:49
(Yes, it's a messy arrangement. That's what branches are for. :P)
timotimo aye. 19:50
huh. i'm getting a segfault from one of my _16 instructions
(gdb) print cur_op 19:51
$1 = (MVMuint8 *) 0x7fbcc8a8c5d0 <Address 0x7fbcc8a8c5d0 out of bounds>
?!
19:54 flussence joined, _sri joined
timotimo cur_op = 0x7f44459c25d0 <Address 0x7f44459c25d0 out of bounds> 19:55
bytecode_start = 0x7f44459c2418 <Address 0x7f44459c2418 out of bounds>
????
setting spesh_disable doesn't fix it :\ 19:56
jnthn Well yeah, you can't just blame spesh for your own bugs :P
timotimo yeah, apparently 19:57
jnthn You did change the increment to be correct after reading it, yes?
timotimo ... reading? 19:58
i'm confused 19:59
jnthn in interp.c
the cur_op += thingy
timotimo hahahahaha
forgot to goto next :D
yeah, that works better now :D 20:00
goes from 3.9mb to 3.8mb for the stage0 files 20:02
3940total -> 3868total 20:03
so that's not the drastic win i was hoping for :Ä 20:04
:P
nwc10 timotimo: it will still be very useful on platforms that can't do 32 or 64 bit unaligned reads 20:05
timotimo oh, huh.
it doesn't seem like these made it into the output at all
jnthn Aye, unaligned reads cost an ARM and a leg in some places... 20:06
timotimo oh, duh
i reset the source for measuring purposes.
yup, that does look like it works. 20:07
would you accept my i64_* work into the spesh_trace branch right now, and squashing a new stage0 onto the lexopts branch of nqp? 20:08
jnthn Can I see the diff? 20:09
timotimo sure
gist.github.com/timo/00aac0df68b1e0afaae1 20:10
i hope you didn't fall over backwards when you saw how i did it %) 20:22
jnthn no no no
spesh ops must come last
timotimo oh
jnthn thought he noted that at the top of oplist
timotimo in the interp.c switch or oplist.txt?
oh!
yeah, i can easily fix that, hold on.
jnthn well, both 20:23
interp suould follow oplist order
Rationale for this is that you can't write spesh ops in bytecode
nwc10 $ ./perl6-m -e 'shell("uname -a")' Linux gcc1-power7.osuosl.org 3.8.8-202.fc18.ppc64p7 #1 SMP Thu Apr 18 14:11:12 MST 2013 ppc64 ppc64 ppc64 GNU/Linux 20:24
jnthn So those don't need to have stable numbers
timotimo yes, of course
nwc10 gah, got nommed
timotimo i brainfarted that fact for a second there :)
nwc10 $ ./perl6-m -e 'shell("uname -a")'
Linux gcc1-power7.osuosl.org 3.8.8-202.fc18.ppc64p7 #1 SMP Thu Apr 18 14:11:12 MST 2013 ppc64 ppc64 ppc64 GNU/Linux
jnthn omg ppc64 too \o/
nwc10++
nwc10 yes, OM${expletive}G
it was surprisingly easy
timotimo not bad!
jnthn :) 20:25
nwc10 although the nativecall test might be trivial, or impossible without assembler knowledge
jnthn Depends what state dyncall is in on ppc I guess
nwc10 it was actually faster that the $other-expletive stuff to get uname probing was
jnthn I *thought* it was in good shape
nwc10 jnthn: it seems to want to be ppc32
so it might just be configure
what's wierd is that the atomic ops stuff worked
timotimo okay, the changes are in there now. i could still build an nqp with it 20:26
20:26 _sri joined
nwc10 whereas IIRC when I was playing with AIX a couple of months back, it wasn't implemented 20:26
20:26 flussence joined
nwc10 and the two machines have the same CPUs 20:26
timotimo whereas a rakudo build gives me Stage parse : Internal error: invalid thread ID in GC work pass
which i believe is known 20:27
jnthn: should i update the gist for you?
nwc10 sparc is hating me:
Updating submodules .................................... FAIL git error: fatal: Needed a single revision
Unable to find current revision in submodule path '3rdparty/dyncall'
aha, it's git 1.5 20:28
maybe that's the Yak to shave
jnthn timotimo: I didn't know that one on Rakudo build.. 20:29
timotimo oh? 20:30
jnthn timotimo: It's been working fine for me on spesh_trace fwiw
timotimo with SPESH_DISABLE set it works
only Stage mast : Error while compiling op execname: No registered operation handler for 'execname'
which is not surprised
surprising
huh.
jnthn timotimo: Yes, can do an updated gist 20:32
timotimo ~on an older rakudo i can build with spesh disabled 20:33
updated 20:34
oh
now i could get through the setting even without disabling spesh 20:35
so it may even be spurious if we're very lucky
jnthn if ((MVMint16) iv->value == iv->value) {
timotimo i asked you if that sounds sane :)
jnthn I'm...not sure that's too robust...
I think it's probably better to compare it with the max/min allowable values 20:36
timotimo OK
FROGGS jnthn: is there an optimization about exception handlers going on? 20:39
jnthn No
FROGGS hmmm
I have a weird problem and it does not make sense at all 20:40
jnthn Not in spesh, anyway
All it does is make sure it rewrites a new set of handlers at code-gen time with the right addresses for the new bytecode.
FROGGS this does print twenty times 1: perl6-m -e 'my $y; my $x; FOO: while $x++ < 10 { say($x); last if $y++ > 20; redo }'
this does print 1 to 10: perl6-m -e 'my $y; my $x; FOO: while $x++ < 10 { say($x); last if $y++ > 20; redo FOO }'
and in the first example it does not search for the handler for some reason 20:41
timotimo now i use INT16_MIN and INT32_MIN and _MAX from stdint.h 20:43
FROGGS eww, rakudo's optimizer does something strange 20:44
timotimo oh no! 20:45
probably my fault :(
FROGGS gist.github.com/FROGGS/bc7635a8a9a1087601b4 20:46
the results depends on the phase of the moon
I run it through valgrind
I'll*
timotimo well. now i got a segfault
that's not much better
FROGGS ahh okay, my fault 20:47
timotimo gc work pass thingiemajig 20:49
i don't understand why that happens 20:50
jnthn m: say 4 / 4.87 # spesh helps once Rakudo's optimizer knows the %_ opt 21:05
camelia rakudo-moar aff2a6: OUTPUT«0.821355␤»
FROGGS OHH MY GOD I AM SOO STUPID!!!111
I copy+pasted this to class Label.next/.red/.last: 21:06
#?if !parrot
nqp::setextype($ex, nqp::const::CONTROL_NEXT + nqp::const::CONTROL_LABELED);
#?endif
unmodified!
>.<
lost an hour due such a thingy :( 21:07
to*
jnthn :(
timotimo our internet compiler is going to drop now. 21:08
er..
connection
FROGGS ewww
but anyway, I am happy that I found it
dalek arVM/small_const_i64: 736a9f5 | (Timo Paulssen)++ | / (7 files):
write small const integers as 16 or 32 bit insts
timotimo so i pushed my changes
FROGGS: i'm glad you were able to find it 21:09
FROGGS yeah
timotimo these kinds of problems usually drive me totally crazy, too
dalek arVM/loop_labels: 4d4841a | (Tobias Leich)++ | src/ (2 files):
do not read uninitialized memory
 21:10
21:10 colomon joined
timotimo i'll have to teach spesh about these new const instructions, too 21:11
but that's easy
i'll do it while the 'net connection is gone
FROGGS timotimo++
dalek arVM/spesh_trace: abaec70 | jnthn++ | src/core/op (2 files):
Add some missing :pure markers on some spesh ops.

Means we can optimize out some more dead instructions.		 21:12
arVM/small_const_i64: 25da6d1 | (Timo Paulssen)++ | src/spesh/facts.c:
introduce the const_i64_* ops to spesh.

also, switch/case is a bit nicer to look at.		 21:16
21:30 ChanServ joined
jnthn ChanServ: Nice vacation? 21:40
:)
FROGGS :o)
timotimo jnthn: would you like me to merge that branch somewhere? or wait until spesh_trace is in master? 21:43
jnthn timotimo: Well, maybe it's nice if spesh_trace can get some testing without that, on something other than Windows... 21:46
timotimo OK 21:48
TimToady who is doing that? 21:58
jnthn Whoever volunteers 21:59
I should really update lexopts in NQP to ahve stuff from master to make it easier...
And similarly get master updated with spesh_trace 22:00
jnthn does it
eeks, conflcits
Testing merges here 22:05
uh 22:07
post merge we get busted bootstrap...
ah... 22:09
yeah, mis-merged. 22:11
dalek arVM/spesh_trace: 61f9cdb | (Tobias Leich)++ | / (10 files):
implement op execname, which stores the path of the runner

We can set the path to the runner in the runner scripts itself, store that information and retrieve that later through nqp::execname. moritz++		 22:12
arVM/spesh_trace: d6a554f | (Timo Paulssen)++ | src/spesh/facts.h:
remove duplicate words from from comments
arVM/spesh_trace: 29c5c9d | jnthn++ | / (11 files):
Merge remote-tracking branch 'origin/master' into spesh_trace
22:17 dalek joined
jnthn ok, spesh_trace + lexopts + nom ready for testing by others 22:18
retupmoca builds 22:25
Stage parse : make: *** [CORE.setting.moarvm] Segmentation fault 22:29
o.O
(linux on x86_64, gcc 4.8.1)
jnthn: ^
jnthn ah shit 22:30
Works fine on Windows :/
Any chance you can do a debug build and get a backtrace?
retupmoca this is moar 29c5c9d925614b002ae2ce3e7c51523a0ce0b53f, nqp 7d6bcb28ce053be71de7bd643c3336eaa2ca5732, rakudo b2b6b19ac74509ff30aee7ef74a1ca142bfe5a81 22:31
that correct?
retupmoca starts up a debug build
jnthn yes, those match what I have 22:34
timotimo will try it soon-ish
jnthn Seems I have a working decontrv improvement patch also 22:38
timotimo neato 22:40
that will remove decontrv at spesh time if we know it's fine without?
jnthn No, just done the opt patch at the moment
Will go for the spesh one later
timotimo compiles for me 22:41
retupmoca mine is sporadic
hah! got a core dump 22:44
jnthn: c-level backtrace: gist.github.com/retupmoca/86d58d4d8d707f26b980 22:45
jnthn Hmm, which is when we mark spesh slots 22:46
retupmoca also, it refuses to die when I'm running it under gdb 22:48
jnthn zombie moar 22:51
retupmoca oh 22:52
this might be my system again
This is nqp version 2014.04-48-g7d6bcb2 built on MoarVM version 2014.04-97-g29c5c9d 22:53
which is not the version I typed make install on :/
retupmoca blows away everything
jnthn retupmoca: Please can you try with this patch: gist.github.com/jnthn/9ea815130e5d361c5e62 22:55
retupmoca jnthn: how do I apply that? 23:02
git apply says it's corrupt 23:03
oh wait, I think I killed the whitespace...
that's better
jnthn Then, probably by using git apply without destorying the whitespace :P
retupmoca still segfaults (although I didn't rebuild nqp yet) 23:05
jnthn hm 23:06
so it's not that
retupmoca jnthn: I added a bunch of gdb print statements in gist.github.com/retupmoca/86d58d4d8d707f26b980 23:13
&body->spesh_candidates[0].spesh_slots[5] looks like the bad one
jnthn What is num_spesh_slots? 23:14
retupmoca (gdb) p *(&body->spesh_candidates[0].num_spesh_slots) 23:15
$18 = 111
jnthn That's a lot of slots... :)
If you probe body->name you can also find out which static frame it is 23:16
Or cuuid 23:17
It's a MoarVM string, so it'll need a little digging
But if I have that, then I can look at a spesh_log and figure out what kind of opt is using slot 5.
retupmoca Can I treat MVMString->body.storage as a char* ? 23:18
jnthn no, it's basically a bunch of int32s 23:20
If you can call functions you can pass the string to MVM_string_utf8_encode_C_string
And that will give you a char *
retupmoca core dump, so I can't call anything 23:21
jnthn ah, too bad 23:23
If you can view a region of memory then you can do it
Otherwise it's just picking through the int32s one at a time...
retupmoca jnthn: body->name looks like 'container_type_info' ? 23:28
jnthn Thanks. 23:29
I'm getting a bit tired now, but I can investigate that tomorrow.
Though if you did have inclination to dig further, set MVM_SPESH_LOG=spesh_log or so in your env var 23:31
retupmoca k
jnthn uh, in your env
retupmoca ooh, I'll do that
jnthn spesh_log is just a file name
YOu can search for container_type_info in that
You might look for slot 5 in there
sp_getspeshslot ops can be interesting 23:32
Though a few other ops do them too
Of note sp_findmethod or so
On the interesting one you've see a liti16(5) or so
Note, it's a lot of output :) 23:33
retupmoca 1.5 million lines, I see
jnthn Also you'll find 3 entries: one "before"/"after" pair which is when it inserts the sp_log things, which isn't so interesting probably, and then one headed "Finished specialization" which is the interesting one. 23:34
timotimo retupmoca: figure out how to use my moarvm gdb plugin :) 23:35
it says how in the top of the file
jnthn Basically what you're looking at in that file is a control flow graph
Just looking at this file can be a bit interesting from an opt perspective... 23:37
existspos r26(9), r22(13), r26(8) 23:38
p6box_i r30(1), r26(9)
set r27(7), r30(1)
if_i r26(9), BB(18)
That's from assign_pos
That boxing is not a good thing... 23:39
And explains the C-level profile showing p6box_i up in a benchmark that shouldn't really have any...
timotimo well, depends on what the r27(7) is used for afterwards 23:40
jnthn *nod* 23:42
Well, that's worth looking into at some point, anyways.
Anyway, 'night
timotimo gnite jnthn!
retupmoca jnthn, timotimo: my spesh_log for a segfaulting run is at drive.google.com/file/d/0B2NGpceqE...sp=sharing 23:44
timotimo did you check out the spesh_diff.p6 script? :)
(as well as the python plugin for gdb) 23:45
retupmoca ooh, I like that gdb plugin 23:47
timotimo yw :)
make: *** [lib/Test.moarvm] Segmentation fault (core dumped) 23:48
not as happy öbout this :(
gc_mark of MVMStaticFrame i think
but i have --optimize=3, which may be a source of instability 23:49
Internal error: invalid thread ID in GC work pass - getting that now 23:51
retupmoca yeah, that's what I'm getting (sporadically) 23:52
while compiling the setting with spesh_trace/lexopts/nom
timotimo yeah 23:53
time to valgrind? %) 23:56
now i got a compilation through
but the perl6-m can't run my spesh_diff script 23:57
i get either a segfault or the illegal thread id thing 23:58

Powered by Cro and the Raku® Programming Language.

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

Thank you!