timotimo oh 00:00
i misread
the previously existing block 2 got kicked out, but the predeccessor didn't get kicked out of the list of then-3-now-2 00:03
00:07 colomon joined 00:08 lizmat joined
dalek arVM: b5b5435 | timotimo++ | src/spesh/optimize.c:
reinstate set removal as a further pass for spesh
 00:12
timotimo huh, i wonder why we don't cache PHI op infos 00:52
i think i'll put a cache on the spesh graph 00:56
that'll be worth it. 00:58
whoa, what ... 35 PHI in 0x9626b0's 0x36feaf0 for 111 args (32) 01:09
now that i think about it, maybe it'd be better to hang the cache off of the tc 01:13
during the nqp build, we allocate PHI nodes with this many arguments that often: gist.github.com/timo/3c69bbced88045475dee 01:19
there's a potential saving of 32 byte for every single allocation, though these used to happen inside spesh alloc blocks 01:20
so all that can happen is they contribute to "tipping the scales" toward fewer spesh blocks allocated
and they'd only count for maxrss for extreme situations or for spesh graphs that live until the end of the program 01:21
(the gist now also contains the same stats but for the whole rakudo build) 01:24
oh 01:47
hmm, the addresses of the PHI ops should probably not move during a spesh run, that'd be pretty ... not good to say the least
so realloc isn't a good idea 01:48
still, having like 4kb of space "wasted" on phi node data doesn't sound like a big deal, compared to allocating 4kb of memory inside a spesh mem block for just 2-arg phi nodes 01:49
and when i blow the cache ... no big deal, i'll just spesh_alloc it 01:50
timotimo is pleased 01:54
02:47 ilbot3 joined 03:17 vendethiel joined 03:26 rurban joined 03:35 colomon joined 04:02 FROGGS_ joined 08:12 rurban joined 08:30 vendethiel joined 08:36 virtualsue joined 09:09 brrt joined 09:11 zakharyas joined 09:56 donaldh joined 10:16 virtualsue joined 10:17 dalek joined 10:38 Ven joined 10:42 Ven_ joined 11:03 kjs_ joined 11:09 tadzik joined
nwc10 [Coke]: do you know if anyone is actually testing the MoarVM macport on PPC? 11:49
12:24 Ven joined
FROGGS_ the PR's of cygx look very good I think 12:42
12:48 kjs_ joined 13:15 Ven joined
[Coke] nwc10: moarvm has no tests, so ... not really? 13:30
I think macports has a buildfarm, though.
nwc10 Well, "testing that it builds" 13:31
[Coke] one sec.
if we got universal support working, we'd have a better idea. See the moarvm ticket for respecting cflags, ldflags from ENV. 13:33
09:40 < neverpanic> [Coke]: we have buildbots down to 10.6, see build.macports.org/waterfall 13:40
09:40 < neverpanic> none for PPC machines, though.
nwc10: you could ask kid51 to test it. 13:41
FROGGS_ [Coke]: can you try to get an answer for github.com/MoarVM/MoarVM/issues/182 ? 13:43
13:44 Ven joined 14:11 zakharyas1 joined
[Coke] I had assumed it was CFLAGS and LDFLAGS. :) 14:45
checking.
nwc10 [Coke]: I don't have time to actively fix problems, so if it's not actually hurting any existing users, I don't feel that it's worth finding more work that needs doing 14:46
[Coke] nwc10: quite fair. 14:47
FROGGS_: looking at guide.macports.org/chunked/referen...ases.html, I think it's those literal flags. 14:48
FROGGS_ nwc10: that's what I thought about the libffi ticket...
nwc10 FROGGS_: do you have the URL for that handy? I've forgotten which it is 14:49
FROGGS_ nwc10: github.com/MoarVM/MoarVM/issues/183 14:50
nwc10 aha that one 14:51
I think that that ticket's reasonable to leave open as a wishlist
14:53 Ven joined
FROGGS_ aye 14:54
[Coke] FROGGS_: Ionic++ from #macports chimed in. 15:01
#182 is blocking us building with +universal support, which would get us a 32 bit build in addition to the 64bit one.
FROGGS_ I see 15:02
[Coke] (it would theoretically get us a powerpc build on older OS Xes) 15:03
15:06 Ven joined
dalek arVM: 0939358 | FROGGS++ | Configure.pl:
use env's CFLAGS and LDFLAGS if set, fixes #182
 15:07
FROGGS_ LDFLAGS=-lfoo CFLAGS="-Dfoo -Ubar" perl Configure.pl --prefix=/home/froggs/dev/nqp/install --optimize --debug=3 15:10
linking libmoar.so
/usr/bin/ld: cannot find -lfoo
[Coke] Seems legit. 15:25
asking if the macports people can test without an official release to shove in a portfile.
15:40 FROGGS joined 16:14 dalek joined
[Coke] wow, ionic took your commit, made a patch of it, and applied it to the existing macport. 16:42
so now the macport for the last release can build universal. 16:43
FROGGS [Coke]: yes, packagers are used to do that :o)
[Coke]: is there a page where one could see the build stats?
[Coke] build.macports.org/waterfall is the only page I know of. 16:53
jnthn the whole course and can now go home :) 17:02
github.com/MoarVM/MoarVM/pull/185 looks good overall, I think, but probably main.c wants updating to use the new functions 17:04
The warnings one...urgh, I have myblah as a naming scheme. :P 17:06
But yeah, it's fine overall.
timotimo jnthn: +1/-1 on caching the MVMOpInfo for PHI nodes? 17:10
jnthn uh, I don't understand what there is to cache?
timotimo 32 bytes that used to be allocated up to hundreds of times per spesh graph 17:11
jnthn Ah, for each phi? 17:12
timotimo yes
jnthn hm
timotimo i got that idea when i wanted to reduce the number of arguments to a specific phi node and noticed i'd've had to allocate a fresh MVMOpInfo for that
jnthn ah, yeah
That's not such a common thing to want to do... :)
timotimo in the "eliminate iffy" optimization i wanted to directly kick out bb's that were made unreachable 17:15
and by reducing the incoming arguments to a phi, i thought i could probably get better facts (when a phi turns into basically a set)
like in gist.github.com/timo/bc2b12f65bbced5a7d8a we're checking a p6box_i'd int if it is concrete 17:17
17:55 nebuchadnezzar joined
timotimo well, with my changes, that spesh log looks a bit better 18:35
oh interesting, that constant 1 is there because logging has found out that the majority of STORE_AT_KEY calls are made with a hash that has a defined $!storage 18:43
things like that are nice to see
18:48 dalek joined
timotimo i'd love to know more about how to get our code-gen from spitting out p6box_i for lots of nqp::blah conditionals like defined 18:55
in this case it seems like it was the || operator to have an "unless" type of deal 18:56
but that also tries to sink the integer >_
>_
>_<
FROGGS [Coke]: build.macports.org page is very confusing :o) 19:14
19:17 virtualsue joined
[Coke] yup. :) 19:48
I think it's rganized by commit, but each commit test only runs the things that changed.
so if you're looking for a -portfile-, good luck.
dalek arVM: eb60fa6 | timotimo++ | src/ (4 files):
reduce pressure on spesh_alloc from PHI op info

by hanging a cache off of the ThreadContext.		 19:59
MoarVM: af415de | timotimo++ | src/spesh/ (2 files):
MoarVM: when killing off a BB, have fun with facts and PHIs
MoarVM:
MoarVM: we reduce usage counts of all registers read in our bb
MoarVM: and we mark all written-to registers as "written from a
MoarVM: dead bb" and when a PHI is seen with arguments that are
MoarVM: from a dead bb, we can cut the register out of the PHI.
MoarVM: If the phi turns too short, we can ignore it completely
MoarVM: and just copy all facts.
arVM/spesh_tune_alloc: 8631951 | timotimo++ | src/ (4 files):
reduce pressure on spesh_alloc from PHI op info

by hanging a cache off of the ThreadContext.
timotimo does somebody want to try out the spesh_tune_alloc branch? :)
it might give a bit of memory savings
then again, maybe not.
now i notice i should perhaps spectest ... 20:00
20:00 dalek joined
jnthn timotimo: tbh, I'd have hung a cache for them off the spesh graph 20:14
It's less re-use, sure, but looser coupling. I already dislike how much stuff is in ThreadContext, this doesn't cut it for deserving to be in there for me. 20:15
timotimo understood 20:18
i can make that change
jnthn cool 20:19
timotimo++
timotimo i'll allocate that cache in the spesh alloc blocks in that case 20:24
do you have an idea how to connect guards, deopts and registers that have had their usage counts bumped up through them? 20:25
jnthn Not right off hand. 20:26
timotimo damn, now i do get segfaults :\
jnthn It's probably worth doing though.
I think the guards must have some state, 'cus we track if we make use of them... 20:27
timotimo we have a "from_guard" flag on our facts, iirc
and a "guard" member that points to the guard?
jnthn ah, could be 20:28
timotimo gist.github.com/timo/d1d710c3141ee41ec88e how did i make this happen :( 20:33
20:34 colomon joined
timotimo am i making bad code-gen? 20:34
jnthn Very possibly 20:35
Or breaking deopt
nwc10 timotimo: I got through an ASAN build of the (current) origin/spesh_tune_alloc 20:49
spectest seemed to fail only the same things as failed on Moar master
(naughty #perl6, leaving the spectest in a state of fail) 20:50
& # bedtime 20:51
timotimo oh? 20:56
t/spec/S02-types/deprecations.t and t/spec/S02-types/isDEPRECATED.rakudo.moar segv for me inside the GC 20:57
er, not inside the gc
that was with an earlier build
both in iscont_i, interestingly
21:02 agentzh joined
timotimo oh, perhaps in treat_perhaps_unreachable_bb i have to make sure to bail out if there are annotations or something like that 21:08
21:10 virtualsue joined
jnthn You need to be really careful about handler annotations 21:12
timotimo i don't really understand why we have to skip inlined BBs for dead bb elimination 21:13
jnthn Probably because we don't do a good enough job of incorportating them into the overall graph. 21:18
I get segfaults in spectest with latest MoarVM/NQP/Rakudo :/ 21:27
FROGGS :o( 21:28
timotimo yes, gimme a bit 21:29
i just nommed a tasty nom
jnthn MVM_SPESH_DISABLE fixes them. 21:30
Why did a commit to spesh that breaks spectest make it into master?
That's *the* test suite we should try any non-boring spesh change against.
At a minimum. 21:31
timotimo yes, very. my bad!
jnthn Is there a commit I can revert locally?
FROGGS eb60fa6 and af415de I guess
jnthn I wouldn't mind spectesting the patch I have here to catch attributes usages in regexes at compile time and complain about 'em.
timotimo most probably af415de
eb06 ought to be harmless 21:32
21:34 colomon joined
jnthn Yes, that helps 21:34
21:40 kjs_ joined
timotimo has_handler_anns doesn't seem to help things here 21:42
i added another check - for "inlined" - and if that doesn't help, i'll revert it globally 21:46
yup. has to go for now :( 21:48
FROGGS move it to a branch first 21:49
timotimo the time traveling nature of git allows me to do it after the revert
FROGGS true :o)
timotimo sad, because it makes some code a little better 21:50
japhb
.oO( Git users do it ... in a branch. )
 21:54
22:39 donaldh joined
donaldh nqp: QAST::WVal.new[0] # jvm gives java.lang.RuntimeException: This type does not support positional operations 22:40
sorry camelia
22:41 vendethiel joined 22:42 camelia joined
camelia nqp-parrot: OUTPUT«Can't exec "./rakudo-inst/bin/nqp-p": No such file or directory at lib/EvalbotExecuter.pm line 188.␤exec (./rakudo-inst/bin/nqp-p /tmp/tmpfile) failed: No such file or directory␤Lost connection to server irc.freenode.org.␤» 22:43
..nqp-jvm: OUTPUT«Can't exec "./rakudo-inst/bin/nqp-j": No such file or directory at lib/EvalbotExecuter.pm line 188.␤exec (./rakudo-inst/bin/nqp-j /tmp/tmpfile) failed: No such file or directory␤Server error occurred! Closing Link: ns1.niner.name (Quit: camelia)␤Lost connection…»
( no output )
dalek arVM: 0988f1b | timotimo++ | src/spesh/ (2 files):
Revert "when killing off a BB, have fun with facts and PHIs"

This reverts commit af415decf100febfc42ee56f10b6d48c5c20d5e4.
Causes segfaults in the spec tests		 22:57
MoarVM: ab259ba | timotimo++ | src/ (4 files):
MoarVM: move Phi cache from TC to SpeshGraph
MoarVM:
MoarVM: Conflicts:
MoarVM: src/spesh/graph.c
timotimo this makes things no longer segfault 22: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!