00:01 cognome joined 00:03 cognome_ joined 00:25 cognome joined 01:04 FROGGS_ joined 01:25 cognome joined 01:51 lizmat joined 02:05 lizmat_ joined 02:24 itz joined 02:25 cognome joined 03:25 ventica2 joined, cognome joined 04:02 njm joined 04:03 njm left 04:25 cognome joined 05:23 ventica joined 05:25 cognome joined 05:42 woolfy joined 05:52 ventica2 joined
sergot hi o/ 06:19
06:21 woolfy left 06:25 cognome joined 06:35 FROGGS[mobile] joined 07:31 jimmyz joined
jimmyz can't build rakudo: Error while compiling op p6bool (source text: "nqp::p6bool(1)"): Cannot find method 'mast_compunit' 07:31
FROGGS ohh, then I won't upgrade until jnthn appears :o) 07:34
TimToady I just compiled with master moar and master nqp 07:36
maybe a version bump is needed?
nwc10 has just built Rakudo 07:37
with master/master/nom
FROGGS hmmm, the nqp revision looks good 07:38
NQP_REVISION is one commit better than the mast_compunit introduction
07:39 jimmyz joined
jimmyz sorry, I didn't git pull nqp .. 07:39
FROGGS jimmyz: np 07:40
nwc10 jimmyz: seems that you have identified a missing version bump needed
FROGGS jimmyz: have you reconfigures rakudo at all?
nwc10 oops, let me rephrase that more accurately - identifed that there is a version bump missing. 07:41
FROGGS because invoking 'make m-install' does not care about NQP_REVISION, only Configure.pl does
jimmyz yes, now rakudo builds fine 07:44
Stage parse is 44s vs 42s, and Stage mast 16s vs 14s 07:45
2s lower
nwc10 2s improvement since (roughly) which revision? 07:46
jimmyz since yesterday 07:48
nwc10 nice 07:49
we need more weekends
07:57 zakharyas joined
jimmyz yeah 08:05
08:25 Ven joined 08:35 FROGGS_ joined
jnthn Well, 4s total improvement there :) 08:39
nwc10 at this rate parse time will be negative within a few months 08:40
timotimo jnthn: sadly, lizmat isn't so lucky with the spectest timings :(
FROGGS_ uhh, how negative
nwc10 joke alert! 08:41
FROGGS_ timotimo: well, there was also the thing that fixes the wrap.t
perhaps that was costly? I dunno
timotimo it seems like the timing that is faster also does more tests
which is weird
FROGGS_ O.o
jnthn odd 08:45
My spectest time here is the lowest I've had in a while. 08:46
timotimo strange indeed.
are you willing to tell us your short-term plans? :)
jimmyz esc? 08:47
:P
timotimo well, yeah, but it seems like that's more or less a mid-term thing 08:48
jnthn Well, the things on this month's roadmap for Moar in part. 08:49
Also planning some things that I hope will improve startup time
timotimo "rewrite throws into gotos where possible" is still in front of us, right? as part of the handlers optimization 08:50
nwc10 Any more bloggage? or is coding more fun?
jnthn timotimo: Yeah 08:51
timotimo code-gen on tight code is going to be *so* *good* :)
well, if you consider spesh a part of code-gen, which i do
jnthn nwc10: Will try and post in the next week or so, once I've got more improvements done :) 08:52
nwc10 OMG MOAR improvments. How will we handle the awesome? 08:54
timotimo well~
we are still kind of behind other language's runtimes
when the jit lands, we'll have something only few dynamic language runtimes have outside of the javascript world 08:55
09:15 harrow joined
jnthn m: say so not True 09:25
camelia rakudo-moar 319a78: OUTPUTĀ«Falseā¤Ā»
09:26 brrt joined
brrt \o 09:26
jnthn brrt \o/
timotimo brrt! :)
brrt jnthn: how do you debug stuff on windows
:-)
still alive
jnthn brrt: Using the VS debugger usually 09:27
brrt: There are a few tricks...
Configure with --debug is one of them
Unfortunately, it's silly enough to overwrite the moar.dll PDB with the moar.exe one
I typically hack the Makefile so the link line for moar.dll also has /pdb:$@.pdb 09:28
brrt that explains a bit
jnthn So it spits out moar.dll.pdb for that.
jimmyz it'll be nice if pdb info is in --debug on windows
jnthn The other thing is that --debug leaves the optimize flags in.
Which can be OK, but loses some locals.
If that's in your way, hunt down /Ox /GL in the compiler flags, and /LTCG in the linker flags, and remove them. 09:29
brrt that's no problem for me, i have the same 'issue' with gdb
jnthn Important: if you remove /GL be sure to remove /LTCG too - or the linker SEGVs...or at least the version I have does :D
brrt my point is i need to instruction-step through the jit compiled frame, so i need to break into MVM_jit_enter_code 09:30
and... i can't manage that, but now i know why
jnthn ok :)
09:32 zakharyas joined
brrt do you happen to know a good irc client for windows? 09:38
Ven
.oO(webchat.freenode.net)
jimmyz chatzilla, mirc ...
Ven
.oO(mirc, you'll love the remotes)
jnthn No; I use screen + irssi running on a Linux box and just SSH into it.
That's why I'm always here :)
Ven bnc! 09:39
jimmyz my linode box is down, that's why I'm not always here :(
brrt it seems i have the reverse setup from jnthn then :-) 09:40
ok, pidgin it'll have to be then
brrt bbiab 09:41
09:41 brrt left 09:43 brrt_ joined
timotimo brrt ssh's into his windows machine to irc? 09:43
brrt_ no, i virtualbox into a windows machine 09:44
well, there's a moar.dll.pdb file now
let's hope that gives me some actual symbols
FROGGS_ ... or prince 09:46
timotimo brrt_: jit compilation has its goas set as 2014.08 on moarvm.org; how do you feel about that? :) 10:00
brrt_ uh... well... good question 10:05
i think i'm going to evade that answer only slightly and argue that a compiler is a 'lifetime of work' :-)
timotimo no pressure, html is rw on our server :)
brrt_ basically, i really want to have merged by then 10:06
jnthn Me too
brrt_ so that will give us at least the current JIT capacity; and hopefully also extops, and throws
jnthn Once brrt++ has JIT working on Windows, I'm planning to tinker a bit too. Provided brrt++ doesn't mind. :) 10:07
brrt_ probably extops, if jnthn++ has added the invokish flags to the extops already
brrt_ doesn't mind at all :-)
timotimo i think he already has
jnthn brrt_: I haven't, but I've added a flags mechanism for ext ops, so it should be a 10 minute patch.
(the invokish indicator on ops ain't in master, so I couldn't do that bit) 10:08
timotimo oh
did they end up in esc?
jnthn No, they're in moar-jit
timotimo oh, ok 10:10
merge master into moar-jit and cherry-pick that commit into master? :)
jnthn Or just wait until we merge moar-jit :P 10:14
timotimo or that 10:15
brrt_ hopes we can merge moar-jit after the ABI bugs are fixed? 10:16
jnthn I guess if we leave --enable-jit needed for Configure then it'll be relatively harmless. 10:17
The bigger decision is not actually the merge, but making that the default.
brrt_ ...a haaaaah 10:18
ok, one bug found
right, for compiling lua, one actually needs mingw 10:23
much fun, right?
timotimo :S 10:24
brrt_ to compile luajit, you can't actually use windows nmake, becausee the makefile is too funky
jnthn brrt_: I found binaries somewhere...
sourceforge.net/p/safelua/wiki/LuaJ...0binaries/ for example 10:25
brrt_ yep, have them too :-)
jnthn github.com/malkia/ufo seems another source of binaries 10:27
masak ufo? what a weird and random name for a project. 10:49
timotimo %) 10:54
10:55 brt joined
brrt_ well, what do you know, can't build bitop without lua.h or luaconf.h 10:58
jnthn Oh 10:59
nwc10 brrt_: you're aware that ASAN doesn't like the JIT? paste.scsys.co.uk/410320
jnthn I thought the one I had included bitop...
10:59 colomon joined
jnthn Maybe my one was actually from www.scilua.org/get.html 11:02
brrt_ nwc10: that actually seems a false positive 11:08
tnx jnthn :-) i'll try that one
nwc10 brrt_: if so, it would be the first false positive I've ever seen ASAN report 11:09
are you assuming something about the layout of memory in C arrays that ASAN doesn't want you to assume?
jnthn I think it's a real bug 11:13
MVM_OP_flip does: 11:14
MVMJitCallArg args[] = { { MVM_JIT_INTERP_VAR, MVM_JIT_INTERP_TC },
{ MVM_JIT_REG_VAL, src } };
That's 2 args
Then:
jgb_append_call_c(tc, jgb, op_to_func(tc, op), 3, args, rv_mode, dst);
Where 3 is the arg count
brrt_ yes, that's a bug 11:19
but that's not what ASAN finds
jnthn Oh?
brrt_ in fact, i removed that, and it still happened
jnthn Hm, I found that by looking at the lines ASAN was reporting
brrt_ i've struggled with that one for a bit already
well, i'll change it anyway 11:20
11:20 cognome joined 11:22 cognome_ joined
brrt_ oh, great news folks, nmake only understands $< as a dependency 11:25
much amaze huh
timotimo can has an up to date bail log statistic for my weekly? 11:28
sadly cant build mvm on my phone easily :) 11:29
moritz timotimo: how do I generate one?
timotimo MVM_JIT_LOG blah.txt and theb grep BAIL pipe sort pipe uniq -c pipe sort -n 11:33
for the setting compilation usually
brrt_ MVM_JIT_LOG is the environment variable 11:34
moritz mlenz@mlenz-workstation:~/p6/MoarVM$ git grep MVM_JIT_LOG|wc -l
0
do I need a special branch, or something? 11:35
timotimo phone keyboard not excellent for irc
yes, moar-jit
and --enable-jit
but
for latest nqp, merge master, too
moarvm master 11:36
moritz eeks, that gives me conflicts
timotimo damn 11:37
brrt_ wait
i'll get you a file
moritz I think I know how to resolve it
does NQP need a branch too? 11:38
hoelzro moarning #moarvm 11:41
dalek arVM/moar-jit: 7d70cb7 | (Bart Wiegmans)++ | src/jit/ (4 files):
Don't always write 4 arguments if we have fewer
 11:42
brrt_ no, nqp should just run master
moritz ok, running the command now 11:44
timotimo who reported these memory leaks in moarvm recently?
FROGGS_ timotimo: TimToady 11:46
in his palindrome RC example
moritz timotimo: perlpunks.de/paste/show/53d6384a.5ff2.12a 11:47
jnthn brrt_: Was that the Win32 ABI-bustying bug? 11:48
*busting
brrt_ jnthn: that seems to fix it for me, yes
timotimo thank you, moritz
elems should be very easy to impl 11:49
moritz thought so too
timotimo sp_findmeth a bit more difficult perhaps
moritz not_i should be easy too
timotimo aye
brrt_ sp_findmeth is really painish
jnthn brrt_: Will do a build here
moritz chars, eq_n, ne_n
no idea bout unbox_s
timotimo clone probably as well 11:50
jnthn brrt_: I'd just factor sp_findmeth out into a function and call it...
timotimo unbox_s can get a helper in reprconv
thatd be easy
brrt_ that, or try to do the cached versions first
jnthn brrt_: Unless you want to do the cache check outside and then delegate.
brrt_ right :-) 11:51
jnthn brrt_: Can we merge master into moar-jit?
brrt_ will do
jnthn Otherwise not sure I can build with latest NQP...
Thanks
dalek Heuristic branch merge: pushed 27 commits to MoarVM/moar-jit by bdw 11:53
brrt_ done
timotimo moritz, the most interesting part of implementing something with many bails in spesh is using grep and context numbers to find out what ops usually come after the op you just implemented
brrt_ is reaaaaaally anxious
also, the Makefile is really a huge pain for windows
we / i should fix that some day 11:54
i.e., the /pdb: flag
and, the lack of $< in command lines
etc etc etc
jnthn Yeah, it's nearly hit my "I should fix this" annoyance level
brrt_ it may be my own lack of familiarity for windows, but it hits my annoyance level daily 11:55
with windows
timotimo heh
jnthn brrt_: NQP now builds and tests fine with moar-jit branch 11:58
Sadly, Rakudo setting build SEGVs
brrt_ i'm not out of the forest yet 11:59
:'-(
jnthn No, but given it SEGV'd right at the start of the NQP build before, this is a big step forward.
nwc10 ASAN built MoarVM JIT is currently running tests 12:00
that is progress
er, NQP tests
hoelzro I think I found a Moar bug
gist.github.com/hoelzro/2c02a2b7810aca50b195
with MoarVM = 2014.07-34-g0513b67, rakudo = 2014.07-56-gfd2b197, this prints out the first 10 callframes and then complains about a NULL string 12:01
I dug into it a little bit last night, and I noticed that a GC collection is happening right before then
brrt_ it also means that the bugs are that much harder to catch
hoelzro so I'm guessing that something with the GC and call frames is screwy
jnthn Unlikely 12:02
nwc10 brrt_: NQP tests all pass for MoarVM built with ASAN and JIT (unless I screwed up badly)
brrt_ \o/
nwc10 fails at /usr/local/bin/perl tools/build/gen-cat.pl moar src/Perl6/Metamodel/Archetypes.nqp src/Perl6/Metamodel/Naming.nqp src/Perl6/Metamodel/Documenting.nqp src/Perl6/Metamodel/Stashing.nqp src/Perl6/Metamodel/Versioning.nqp src/Perl6/Metamodel/TypePretense.nqp src/Perl6/Metamodel/MethodDelegation.nqp src/Perl6/Metamodel/BoolificationProtocol.nqp src/Perl6/Metamodel/PackageHOW.nqp src/Perl6/Metamodel/Modges/nqp/lib/QAST.moarvm:as_mast:4294967295)
jnthn hoelzro: I'd guess it may inline something and then fail to undo that when annotations wants its data 12:03
nwc10 but that's not an ASAN failure
brrt_ hmmm
timotimo froggs why did we go back to enumcharlist on moar again? are we using charring by now?
brrt_ that's weird
if i see that line correctly, it's a perl script that fails?
hoelzro jnthn: do you have any suggestions on ways I can help confirm that? 12:04
like some sort of runtime options that I can toggle?
timotimo rob, there is a environment variable to turn off inlining
jnthn hoelzro: set MVM_SPESH_INLINE_DISABLE=1 12:05
hoelzro that breaks too =(
jnthn Well, there's that hypothesis gone then :(
hoelzro oh well, now we know 12:06
the GC code is a bit daunting to me 12:09
nwc10 hoelzro: hopefuly only a "bit" - it's not like it's parrot's GC
hoelzro but I wonder if maybe some object is being created in MVM_exception_backtrace that's not being added as a reference properly or something 12:10
nwc10: I managed to figure out where things were getting called, so it can't be that bad =)
I was looking late last night, so I can give it another go after I've rested and had coffee 12:11
FROGGS_ hoelzro: interestingly we had a bug like a week ago that showed up when compiling a TTIAR 12:13
maybe it is just hidden but still there....
hoelzro ttiar? 12:14
FROGGS_ two terms in a row
jnthn No, that one was certainly fixed...this must be something else.
FROGGS_ ohh, good to know :o)
hoelzro ah ha 12:15
brrt_ doesn't get a segv but a regular error
worse yet, not even a JIT error 12:16
:-)
i probably have the wrong version of nqp
hoelzro oh, it *was* a segv, but then I played a little more to get more info and forgot to rename the file
jnthn brrt_: What is the error, ooc?
hoelzro I got the segv by doing "{caller.file}", iirc
(not sure if brrt_ is referring to my error or not) 12:17
jnthn hoelzro: No, the error I ran into building Rakudo with moar-jit 12:18
hoelzro ah ha
brrt_ jnthn: fixed by updating nqp :-) 12:19
12:20 cognome joined
brrt_ afk 12:21
hoelzro if it's alright with everyone here, I'll file a Moar bug
jnthn hoelzro: Sure
12:28 cognome joined 13:20 cognome joined 13:40 jnap joined 13:53 btyler joined 14:18 lizmat joined 14:20 cognome joined 14:28 woolfy joined 14:42 jnap joined 14:44 woolfy left 14:51 brrt joined
brrt bad news; moar-jit wfm 14:52
meaning that if it works for me, i don't know why it breaks for anyone else
(on windows, even)
timotimo well, it's a good start that it does work
now you can get back to implementing cool stuff and someone else has to find the bug :D
brrt that may be so
make sure y'all have clean versions of nqp and rakudo, and then it please report to me if it still breaks :-) 14:53
as far as i can tell, there are a few high priority things to do 14:56
a): the whole param_* stuff
fwiw, i thought i /had/ chars, but apparantly not 14:57
eq_n is funkier than it seems, too
jnthn oh? 14:58
brrt yes, i've inspected the gcc output, and there are two comparisons to make if you want to check two fp numbers for equality 14:59
[Coke] jnthn: I never did open a ticket on most recent segv; will try to remember to do so today.
brrt sp_findmeth is /really/ big, so i should do that next, i think
hoelzro brrt: is this regarding the segfault when building nqp?
brrt are you building nqp with moar-jit?
on windows?
then yes, otherwise no
timotimo brrt: should i do elems in the mean time? 15:00
brrt if you wish :-)
timotimo well, it ought to help, right? :)
jnthn brrt: Just done a debug build now
brrt does it work for you?
(i always do debug builds, btw) 15:01
hoelzro I just noticed that my useful perl Configure.PL --prefix=/tmp/why --gen-moar --backends=moar hasn't been working today 15:02
...unless I check out a fresh copy of the rakudo repo
it may be unrelated, but it sounded like what you all were talking about earlier 15:03
jnthn brrt: No, SEGV in CORE.setting build still :(
timotimo brrt: we have graphs_s and codes_s, but not chars :)
brrt that's weeeeird :-( 15:04
on moar-jit/master/nom?
jnthn Yup
brrt with --debug?
brrt doesn't get it at all
i think your computer is just conspiring against me 15:05
jnthn Happens in MVM_multi_cache_find_callsite_args
brrt oh really?
jnthn Called from MVM_frame_find_invokee_multi_ok
brrt called from the JIT?
jnthn And then the stack claims to have a ton of frames
dalek arVM/moar-jit: 66bd7e4 | (Timo Paulssen)++ | src/jit/graph.c:
chars is implemented the same as graphs_s for now.
jnthn Bottoming out in MVM_jit_enter_code
brrt hmmm 15:06
ok, i know which fragment of code that is, so that's something 15:08
(it's the slow invoke path)
but it's weird that would break for you but not for me 15:09
jnthn aye 15:10
brrt bbiab
timotimo brrt: how much testing should i do for my implementation of elmes before pushing?
elems*
oh, the core setting segfaults 15:11
isn't that fun
jnthn Darn. If I turn off optimization then it works.
Or is getting a load further
brrt :-o
timotimo well, all the elems i can see are followed by almost exactly the same code, culminating in an atpos_i that bails 15:13
and disabling the jit makes it work ... great ... 15:14
jnthn Yeah, it completed with JIT disabled
oops
with optimization disabled
(as in, C compiler opt) 15:15
timotimo oh?
i shall try that, too
where does your crash happen, ooc?
jnthn About a second into CORE.setting
timotimo mine happens a few frames down from jit enter code inside #0 0x00007f219e41b89d in MVM_multi_cache_find_callsite_args () from /home/timo/perl6/moarvm/../install/lib/libmoar.so 15:16
No locals.
#1 0x00007f219e3eb65a in MVM_frame_find_invokee_multi_ok () from /home/timo/perl6/moarvm/../install/lib/libmoar.so
No locals.
very early in stage parse
jnthn oh, that's exactly where mine is
Ah, so it happens on Linux too... :)
timotimo good to know 15:17
jnthn Oh, interesting...
timotimo i turned --optimize=0 and it still segfaulted 15:18
jnthn If I disable link time code generation and just do normal optimization without that it works
timotimo: I mean C compiler opt
timotimo yes, that's what i gave moarvm's configure.pl
this time the stack is much shorter
frame number 3 seems corrupted, as in: 0x0 15:19
15:20 cognome joined
jnthn brrt: It's compiling with /GL and /LTCG that causes the explosion, it seems 15:21
timotimo this is bad news for me; how am i supposed to test my implementation?
jnthn: should i just push it and let you review it? it's kind of trivial, i believe 15:22
jnthn Well, push to a branch?
And test/merge it to moar-jit once it's possible to test it?
timotimo sure no problem 15:23
implemented atpos_i as well now. 15:26
i can at least use nqp as a little testbed 15:27
dalek arVM/jit-moar-ops: ed91447 | (Timo Paulssen)++ | src/jit/graph.c:
implement elems as call to MVM_repr_elems
 15:30
arVM/jit-moar-ops: c52948f | (Timo Paulssen)++ | src/jit/graph.c:
atpos_i is another hot op (implemented through MVM_repr_at_pos_i)
jnthn timotimo: iter is another hot one 15:32
Should just be a function call
And bindpos_o
bindkey_o too
And existskey 15:33
dalek arVM/jit-moar-ops: e8ab84c | (Timo Paulssen)++ | src/jit/graph.c:
push_i is next, unshift_i can have the very same code.
 15:34
timotimo i'm now following what happens with our parsing 15:36
jnthn I think we'll nail action methods and QAST construction a good bit before parsing. 15:37
timotimo the bails that used to be push_i are now indexat or eqat_s i think
sadly, indexat is a branchy instruction 15:38
doing iter next, then i'll look at if i can add branchy stuff without writing dasm files 15:41
hmm
15:41 colomon joined
timotimo why is dst sometimes MVMint16 and sometimes MVMint32? 15:41
cool, eqat_s is non-branchy 15:43
all of the iterkey_s-used-to-bail are now iscclass bails; interesting 15:46
this is like chasing rabbits %)
hm, i didn't check, but it seems this execution dies earlier and earlier every time i add new instructions 15:51
could that be?
ah
well, now nqp segfaults, too
and really early :) 15:52
dalek arVM/jit-moar-ops: d22e36d | (Timo Paulssen)++ | src/jit/graph.c:
implement iter, iterkey_s and iterval
 15:53
arVM/jit-moar-ops: 7227fca | (Timo Paulssen)++ | src/jit/graph.c:
implement bindpos_o and bindkey_o
timotimo ah, iterkey_s is Very Wrong 15:54
no, it was correct. strings being returned are handled via RV_PTR 15:56
now i don't know how to continue :\ 15:57
i surely hope it's not my fault that things blow up everywhere now %) 16:00
it would be neato if brrt could implement not_i, ne_n and eq_n 16:01
i surely hope this is just a matter of the jit generating bad code under some circumstance and me just triggering that circumstance more often 16:03
or something like that
dalek arVM/jit-moar-ops: 71ab464 | (Timo Paulssen)++ | src/jit/graph.c:
shift_i and pop_i are very simple
 16:04
[Coke] timotimo: what order are things in here: github.com/MoarVM/MoarVM/blob/71ab...aph.c#L111 ? 16:05
16:18 cognominal joined, cognome joined 16:50 japhb joined 17:14 vendethiel joined
timotimo is back from places 17:16
nearly, but not really sorted by opcode value 17:17
:S
dalek arVM/jit-moar-ops: caa93e4 | (Timo Paulssen)++ | src/ (3 files):
getattr_i and eqat_s
17:22 Ven joined
timotimo now i'm beginning to really miss brrt :\ 17:23
dalek arVM/jit-moar-ops: ca03ffd | (Timo Paulssen)++ | src/jit/graph.c:
existskey is another common op.
 17:39
timotimo jnthn: can you look more closely at the box_[ins] instructions? 17:46
oh 17:48
they appear to be correct
i got confused with MVM_repr_box_* and MVM_box_*
dalek arVM/jit-moar-ops: 18fc43d | (Timo Paulssen)++ | src/jit/graph.c:
implement unbox_[ins]
 17:51
flussence Hi #moarvm, I'm hitting this error in some mundane perl6 code, any idea what might be causing it? github.com/MoarVM/MoarVM/blob/mast...ect.c#L421 17:54
(I'm busy bisecting rakudo atm to figure out when it broke) 17:55
timotimo oh yikes
mundane meaning you're using neither multithreading nor asynchronous I/O?
17:56 zakharyas joined
flussence I'm just open()ing some files and slurping their contents, nothing fancy... I did have threading code there but I stuck that codepath behind an env var because it doesn't work; it's running a plain loop and then errors out halfway through with that 17:56
jnthn That tends to indicate heap corruption 17:57
flussence (I wonder if there's some spooky action at a distance going on because the other code's still present-but-disabled)
jnthn It's more likely to be Moar that's interesting to bisect 17:58
flussence well if this bisect lands on one of the nqp revision changes, that'll help narrow it down still :)
jnthn True :) 17:59
timotimo jnthn: i'm looking into speshing objprimspec; the implementation checks if the first argument ("type") is null and if not, returns the storage_spec's boxed_primitive; does that mean i have to check for KNOWN_VALUE or would KNOWN_TYPE be enough? :S 18:06
i fear the former; which would make it useful much less often
except ... i could turn it into an isconcrete + multiply with the storage_spec of the known type %)
jnthn If you know the type I think you can do that 18:07
timotimo that == the isconcrete trick? 18:08
er, i think isnonnull
should be the answer
jnthn No, if you know the type you can actually call get_stroage_spec
And pull the value right out
And that'll be the answer
timotimo oh, if we know the type, that also means the thing wouldn't even be null 18:09
jnthn So it'll spesh to iconst_64_16 or so
timotimo gotcha :)
jnthn Right, we'd not have got that far; we'd have bust a gurad
timotimo oh, does that mean we can turn isnull/isnonnull into constants when we have a known type fact?
jnthn Hmm 18:10
Interesting question :)_
We may get a rather unintended consequence if we do that. 18:11
ah, though maybe not...
timotimo well, how come it's safe in the objprimspec case and not in the other? :)
jnthn I didn't mean it's unsafe 18:13
It's more that ifnonnull and isnull often show up in vivification-y situations 18:14
And you might end up introducing a guard that is going to get broken a lot.
timotimo oh, i didn't even look into how to mark guards as being used yet :\
but yes, that would be unhelpful 18:15
18:16 Ven joined
jnthn At the moment we've very conservative 18:16
If you ask for the facts, it's marked as used
timotimo ah!
jnthn Can do better in the future
timotimo i'll just put a comment in there
for example, if we ended up not doing an optimization, we don't need to mark the guard "used" 18:23
is there perhaps a way to get a "forget i asked about this fact" thing? is the usage thing a counter?
jnthn No, not yet, but that's what we want 18:24
timotimo sounds almost like something i could implement, no? 18:25
FROGGS_ call it SvREFCNT_inc :o) 18:27
jnthn I'd probably rename the current thing get_and_use_facts and switch everything over, then add a get_facts and a use_facts, and then start updating things bit by bit
It's not actually a usage count
timotimo coerce string to int NYI - what.
jnthn Either a guard is used or it isn't 18:28
We don't care how many times
timotimo OK
... how did i get that error message? o_O
oh, that's how 18:29
dalek arVM: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
can do objprimspec at spesh-time
 18:30
arVM: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
but please without debug spam.
nwc10 brrt: ./perl6-m t/spec/S05-match/capturing-contexts.rakudo.moar fails with a spectest, but passes withut 18:38
(I know that he's not here)
the good news was that everything else passed. That's a JIT MoarVM built with ASAN
timotimo jnthn: should we - at some point - be able to only "use" a subset of the given facts and thus generate a less specific guard? 18:39
like: we have known_value, but we only care about known_type in this case?
jnthn known_value is never guarded anyway 18:40
it only happens for wval 18:41
or similar
We guard by type at most
timotimo OK
FROGGS_ nwc10: that are indeed good news 18:42
timotimo OK 18:44
working on the get/use split now 18:48
it'll require changes in rakudo/master, too, so ... hmm
should the "use_facts" function just take the MVMSpeshFacts structure again? 18:53
(and not the tc and g, especially) 18:54
jnthn Well, we always pass tc
Passing g may be wise
timotimo oh, i have to pass g either way
jnthn ah, good :)
timotimo so i can choose if i should pass the operand or the facts 18:55
jnthn Oh
Well, we have the facts, so may as well pass those I gues
*guess
timotimo aye. means less looky uppy action
jnthn: we often have a line like "get_fact(...)->usages--", in that case i can just get the fact without marking it used, correct? 18:58
jnthn Yeah.... get_facts_direct I think does that
timotimo aye, though i introduced a MVM_spesh_get_facts method you can use as part of the public interface 18:59
19:01 woosley joined 19:18 brrt joined
brrt \o 19:19
19:20 itz_ joined
jnthn o/ brrt 19:21
brrt sees all the excitement
timotimo hey brrt :) 19:22
i've made a bunch of ops for you, but moar-jit crashes really early even in an nqp build with my branch ;(
brrt ok, my guess is that compilation with link-time code generation changes the effective call conventions, because the compiler assumes that all will be ok since there are only a limited number of calls 19:23
and you want me to debug it? :-)
timotimo oh 19:24
jnthn brrt: Hm, but I think timotimo++ got a similar crash...
timotimo do we have lto?
nwc10 brrt: (almost) "works on 'my' machine" - why bother with his? :-)
brrt i'll checkout out the moar-jit-ops branch, see if i can see what causes it 19:25
brrt wants a 'gdb is my homeboy' shirt
jnthn timotimo: liquid titanium oil?
Oh, link time optimization...
Well, MSVC does 19:26
nwc10 I can't even build normally with LTO 19:29
I get ./libmoar.so: undefined reference to `.L587'
and a lot more like that
timotimo jnthn: in optimize_call there's a bunch of code that apparently used to do inlining above a call to spesh_inline, can that go? 19:30
also, there's an XXX about being able to remove a lookup of an enclosing code object or something 19:31
have no idea if it's a juicy target or not
19:31 itz joined
jnthn brrt: See msdn.microsoft.com/en-us/library/xbf3tbeh.aspx 19:32
brrt: Of note, "When /LTCG is used to link modules compiled by using /Og, /O1, /O2, or /Ox, the following optimizations are performed:" 19:33
"Interprocedural register allocation (64-bit operating systems only)" is notable maybe
But "Custom calling convention (x86 only)" suggests it's not an issue for us
brrt hmmm
jnthn ooohhh 19:34
Para below is l'important.
timotimo doesn't explain the segfault on linux ;(
jnthn It may be doing similar opts... 19:35
brrt you mean: "If the compiler can identify all of the call sites of a function, the compiler ignores explicit calling-convention modifiers on a function and tries to optimize the function's calling convention:" 19:36
jnthn Right
brrt but /me brb, got an errand to run 19:37
making the affected symbols public should alleviate if this is the case
dalek arVM/split_get_use_facts: 9d377a3 | (Timo Paulssen)++ | src/ (3 files):
split get_facts and use_facts from get_and_use_facts.
 19:40
timotimo ^- looks sane?
19:41 Ven joined 19:43 itz_ joined
timotimo well, almost. 19:46
dalek arVM/split_get_use_facts: be8cfdf | (Timo Paulssen)++ | src/spesh/optimize.h:
fix teh build
 19:47
flussence well this is bizarre, that bisect I was doing... went to sleep. 0% cpu usage in the middle of compiling CORE.setting. 19:48
oh well, it's narrowed it down to either rakudo f1fd505 or 41cd958, so that's a start. 19:49
...reproducible too. weird. 19:53
jnthn flussence: There was one commit that deadlocked setting comp once on non-Windows. 19:57
flussence oh, that'd be it :) 19:58
timotimo probably just noise; with the split_get_use_facts, stage parse might have been faster by 0.5s
yays 19:59
removed 15 guard ops throughout the whole core setting specialization :)
jnthn (I forgot libuv mutexes aren't portably reentrant) 20:00
timotimo 5x type and 10x conc
jnthn: would you like me to merge the branch? :)
jnthn timotimo: Gimme a bit to look at it; got 5 mins more $dayjob task to do then will be able to 20:01
flussence oh, looks like most of this bisect helped anyway: the breakage is between moar 0edddb3..684027b
now to figure out how to bisect those...
timotimo :) 20:02
20:03 brrt joined
brrt back 20:04
timotimo heyo brrt :)
brrt ok, now have time for your bug
timotimo soon, a whole 15 guards less will be part of the setting compilation thanks to spesh! 20:05
it'd be kinda neat if we could track the number of bails per exact guard
(without impacting run time of the rest of the vm if we are not looking)
brrt ok, so i've traced the error to a MASTNode pointing to Not An Object 20:08
i.e., a valid pointer, but very much not an object (thread id 0, st 0) 20:09
jnthn bbi10 20:13
brrt right, chars already presents a problem 20:21
timotimo huh? 20:22
it does? did i do it wrong? :(
brrt no 20:25
the problem is apaprant before that, even
but, at least this is a problem that doesn't appear in the compiler, so it's good for figureing out what hapepns 20:26
timotimo oke 20:29
sadly, i can't get an up-to-date bail log ;( 20:30
brrt i know
timotimo about 510 bails have been pushed forwards from moritz' last measurement 20:31
brrt ok, that's very nice 20:32
20:32 Ven joined 20:35 lizmat joined
brrt ok there's a speshbug in master that crept into moar-jit during the merge and /probably/hopefully/ explains why current moar-jit crashes 20:37
(how do i know it's even a spesh bug? just because) 20:38
i.e. it still happens in my foo.nqp test file despite having compiled a totally-free-of-jit version of moar
the error is that 'this representation (P6Num cannot unbox to a native int)
'
now frankly i wonder why not
timotimo a num? to an int? 20:39
brrt yes
timotimo why does our code assume it's possible? =o
brrt it doesn't (usually), that's the bug
it's not an inlining bug 20:40
timotimo P6num doesn't have a spesh function at least
neither does P6int
brrt so i'm wondering what changed between moar-jits last master merge and now
i should /really/ get to writing a proper jit test suite 20:42
timotimo that seems like a good hint
brrt if that (coupled with param refactor, extops, and throwing) is /all/ i'll do for the next few weeks, i might as well be satisfied 20:43
although i'll never be exactly that, of course
timotimo we still need extops to teach the jit how to jit them :S 20:50
otherwise perl6 code will never actually be jitted! :(
jnthn back 20:52
FROGGS_ just in time I'd say...
timotimo that pun will get old fast 20:53
brrt jnthn has done a lot about that 20:54
basically, with extops i can go two approaches
jnthn Hm, spesh bug?
brrt a): i assume they do anything and everything, so i check all relevvant variables afterwards (i.e. cur op, cur frame, perhaps more?) and fallout if necessary
jnthn How do I reproduce it? 20:55
timotimo i suppose it doesn't surprise that something involving unbox_n didn't get triggered in the core setting compilation or anywhere else in compiling rakudo or nqp ...
brrt git checkout moar-jit foo.nqp ; ./foo.nqp
timotimo nums is hardly something we'd use in the compiler, after all
brrt (from master or anywhere else)
brrt nods
you should see a 'can't unbox P6num to native int' error 20:57
jnthn Yeah, got it 20:58
phew, it's not inlining or OSR related though. 20:59
brrt :-)
i see you've added interpreter support for 'invokish' extops 21:00
jnthn How on earth did that work before... 21:01
brrt i don't know, must've not happened often? 21:02
jnthn Oh... 21:03
args.c is more liberal than I realized
timotimo :D 21:04
seems like we found the culprit :)
brrt that's pretty fast :-o
timotimo that's jnthn for you
brrt afk 21:15
21:16 brrt left
timotimo seems like the patch is getting tested rigorously before being pushed into the 'net :) 21:48
jnthn Well, it seems to help, just that I'm looking into the JIT thing too 21:52
timotimo ah, OK
good to know
when jnthn has fixed the jit thing, too, brrt will be able to implement not_i, ne_n and eq_n and things will be so good! :3 22:05
jnthn grrr, this is a pain 22:10
timotimo i hope you'll persevere 22:14
timotimo ducks
i only ever do the non-painful stuff %)
jnthn aha
timotimo oh, you only noticed that now? :P
jnthn no no :P 22:15
#if defined _MSC_VER
# define MVM_USED_BY_JIT __pragma(optimize( "g", off ))
:)
this seems to help
timotimo can you intuit what the gcc-equivalent is?
also: oh man >_<
jnthn Not easily 22:16
timotimo we'll have to annotate every single function the jit will ever use
jnthn Yeah
timotimo i saw an attribute for gcc that meant something similar i think, let me look again
jnthn In theory this means I can keep ltcg for everything else, though.
timotimo externally_visible 22:18
jnthn I'd have guessed that corresponds to __dllspec(export) or so
Trouble is that didn't do it
Because MSVC just goes and uses funky calling convs and then *notes in the link .lib that it did so*!!!
timotimo ah, hm 22:19
This attribute, attached to a global variable or function, nullifies the effect of the -fwhole-program command-line option, so the object remains visible outside the current compilation unit.
jnthn So anything linking against it can join in the game :P
Hm
timotimo m)
jnthn "remains visible"
timotimo that's nice
yes, not the same i realize
jnthn Waht's -fwhole-program defined as?
timotimo Assume that the current compilation unit represents the whole 22:25
program being compiled.
totally useless for our purposes
i went through the whole function-attributes page of the gcc docs and found nothing 22:26
dalek arVM/moar-jit: fee2d64 | jnthn++ | src/ (2 files):
Add MVM_USED_BY_JIT and add it in one place.

This disables optimizations on a per-function basis that fiddle with calling conventions and so frustrate JIT compilation's calls to them. Only annotated the one that made things explosive on Windows so far, but really we should mark up all that the JIT uses.
timotimo in only one place?
jnthn A volunteer to add MVM_USED_BY_JIT elsewhere would be awesome... :)
(just means looking through src/jit/[x64_emit.dasc& graph.c] for &MVM_* and then finding them in the .c files and pre-pending the macro. 22:27
)
timotimo sounds like a great thing to automize m)
jnthn Go for it ;) 22:30
timotimo nope nope nope :3
dalek arVM: 35919a9 | jnthn++ | src/spesh/args.c:
Do more checking before speshing arg unboxing.

We could end up trying to unbox a num as an int before. While we can spesh that situation, for now just make sure we apply the transform when it really is safe.		 22:34
timotimo i merged that into moar-jit and we still segfault; so i'll actually need to get something proper for the used_by_jit thingie? 22:36
:\
even with --optimize=0
though it just passes no -O option, so maybe -O1 is the default?
carlin did you know you can do --noo as a shortcut to --optimize=0? :D
timotimo noooooooo 22:38
dalek arVM/moar-jit: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
can do objprimspec at spesh-time
arVM/moar-jit: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
but please without debug spam.
arVM/moar-jit: 35919a9 | jnthn++ | src/spesh/args.c:
Do more checking before speshing arg unboxing.

We could end up trying to unbox a num as an int before. While we can spesh that situation, for now just make sure we apply the transform when it really is safe.
MoarVM/moar-jit: b69bd55 | jnthn++ | src/spesh/ (2 files):
timotimo :3
jnthn timotimo: Hm, where do you get segfaults?
But yeah, perhaps 22:39
You could try the pragma you found
timotimo very early in the stage parse of core setting
but the pragma i found is almost certainly useless
how do i figure out what exactly is wrong? :\ 22:41
jnthn Was it in the same place I had the problem?
MVM_frame_find_invokee_multi_ok? 22:42
timotimo i think so, let me get a fresh core dump
#0 0x00007fadbc1f6bc6 in MVM_multi_cache_find_callsite_args (tc=0x1c21600, cache_obj=0x7fadbb935cf8, cs=0x0, 22:43
gist.github.com/timo/65133b28e088277fe0f2
see how there's a 0x00 stack frame?
if cs->has_flattening blows up 22:44
so the cs pointer must be b0rken
oh, yeah, it's null
that's why
i just don't know why it's null :P 22:45
not really good at the assembly thingie
jnthn yes, that's the problem I had too
Before disacling that optimization for that function
timotimo which exact function is that? 22:46
you said you have find_invokee_multi_ok, i have multi_cache_find_callsite_args
oh
duh, it's one frame up
jnthn look donw a frame
or up :)
timotimo i look down on these frames 22:47
jnthn hah, I tried your JIT extra ops branch and omg segv :) 22:48
timotimo i wonder if that's due to more missing used_by_jit annotations or due to me messing stuff up ... 22:49
i explicitly gave moar's cflags a -fno-lto ... 22:50
so that's not it 22:51
jnthn Well, think I see a mistake
timotimo Beware that you must then declare the cdecl or regparm(0) attribute for a function that will follow standard GCC calling conventions. See C Extensions::Extended Asm:: section from the GCC info pages. See also how Linux defines its asmlinkage macro.
jnthn hah, and after fixing that it works 22:52
Mind that I merged moar-jit into your branch?
timotimo no problem
feel free to merge it back as well
or just merge it back and drop the local other-direction merge :)
and cherry-pick the fix etc etc
dalek arVM/jit-moar-ops: f92fdd6 | (Timo Paulssen)++ | src/spesh/optimize.c:
can do objprimspec at spesh-time
 22:53
arVM/jit-moar-ops: 587ca47 | (Timo Paulssen)++ | src/spesh/optimize.c:
but please without debug spam.

Correct an arg count.
timotimo there is a -mrtd flag for gcc
does that seem familiar?
jnthn Not to me.
22:53 dalek joined
jnthn Taht fixes the SEGV, but unfortunately we now get a hang in NQPHLL.nqp compilation. 22:55
timotimo so ... do i want cdecl or stdcall?
d'oh
jnthn I guess cdecl 22:56
timotimo unfortunately -mrtd seems to force the opposite 22:57
22:58 brrt joined
brrt yeah, if you could not steal the thunder of my awesome bugfixing commit that changed the arg count.. that'd be great 22:58
i literally have the same commit ready to push :-D
jnthn ;-)
At least I fixed the Win32 thing
Do you get the hang in NQPHLL.nqp too?
brrt oh, awesome 22:59
what hang? not yet i didn't
jnthn When I build NQP with 34d35ec it hangs
brrt i see 23:00
weird
jnthn Doesn't with plain moar-jit 23:01
timotimo src/core/frame.c:1234:1: warning: ā€˜__cdecl__ā€™ attribute ignored [-Wattributes]
jnthn So should be easy enough if nobody else can reprouduce it for me to go through the commits
brrt __cdecl__ isn't relevant in x64
timotimo brrt: well, how do i fix the segfault then? :(
i really want the jit to work
brrt which segfault?
brrt confused 23:02
timotimo the segfault i've been constantly getting :)
brrt that one? git pull
timotimo gist.github.com/timo/65133b28e088277fe0f2
jnthn brrt: Before I added MVM_USED_BY_JIT I got the same SEGV as timotimo here on Windows.
brrt oh, that's the windows one
jnthn brrt: cs was invalid
brrt what? where do you get it?
:-o
jnthn brrt: Since I added MVM_USED_BY_JIT it's gone on Windows 23:03
brrt that's weird...
jnthn I basically stopped LTCG going and doing...something...
brrt uhuh
jnthn But timotimo now has the same issue on...Linux with gcc I guess.
timotimo yes, linux with gcc
brrt i had expected it'd be necessary to make the symbol public, but this works
but linux and gcc don't use LTO?
jnthn Yeah, I tried public first.
Well, thing is...I don't *know* that it's calling convention related. 23:04
What I disabled really are "global" optimizations
timotimo for now i have to run get a tram
timotimo packs
brrt hmmmmm 23:05
jnthn msdn.microsoft.com/en-us/library/1yk3ydd7.aspx
brrt wonders what version of gcc timotimo uses
basically, it'd just be 'weird' if the callsite was all wrong like that 23:06
timotimo gcc (GCC) 4.8.3 20140624 (Red Hat 4.8.3-1)
brrt that's the same as i have
jnthn brrt: Yes, I'm wondering, given it seems to do register opts, if there's some weirdness going on with that...but I don't see where 23:07
It *is* strange we hit the same SEGV on two completely different compilers.
brrt i suppose you're using the register view?
jnthn No, I just wsa reading the thing I linked above
brrt yes, especially if it is in fact optimization related
ok, i should do that too then 23:08
although, first, i should probably repeat the crash 23:10
why is gdb printing nqp source code at me? 23:11
jnthn o.O
brrt oh, because one of them is the argument to a string 23:12
timotimo i turned optimisations off for moarvm 23:13
brrt and what happened then? 23:16
timotimo the crash you see in the paste 23:17
jnthn Got a meeting in the morning...sleep time... o/
timotimo gnite jnthn
brrt \o
ok, i'll do the same then 23:18
timotimo brrt fix my thing
nnnooooooooooooo
brrt what?
timotimo how am i supposed to sleep
brrt why shouldn't you be able to sleep?
timotimo can you at least give me a new jit log?
brrt sure, of what? 23:19
timotimo not knowing what is wrong will keep me up
core setting would be nice
brrt :-)
well, can't get there right now, because as jnthn++ so rightly said, moar-jit hangs on something
'something? what's something?' 23:20
hell if i know
timotimo also... having a log of the compete compilation of everything, nqp and rakudo, would be interesting
brrt yes
timotimo then just build nqp without jit
and just the core setting with jit
:)
brrt i'll try :-) 23:21
timotimo cheat as much as you have to
yay
if you paste the whole log I can do more science to it
brrt will do just that 23:23
timotimo a truncated log would be fine as well
if the core setting hangs as well
thx :) 23:24
brrt i'll have to see if that happens
timotimo I may write an analysis script for the jit log 23:26
brrt gist.github.com/bdw/9abb46e9e4a3d0bc2cc9 23:27
brrt is now afk for real tonight 23:29
23:29 brrt left
timotimo used to be 1588 bails (when moritz pasted his stuff) and now is 1149 in the truncated jit log 23:53
it's hard to tell if it'd be the same number if it weren't truncated ... 23:54

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!