timotimo hum. 00:04
i turn the param_op_o into a goto and the BB link is correct
but the first ten invokes of my method say "hello", the rest say ""
haha, i seem to have exactly confused passed and non-passed 00:05
hm, no, not quite 00:06
the first 10 invocations are okay, the rest are wrong 00:09
if i negate the condition in the changing code, it turns from "first the default value, then no value" to "first the passed value, then the default value"
oh, i have to *drop* the operation 00:10
ah, if the thing was set it will write and jump 00:11
i had that exactly backwards
but there's only a manipulate function for deleting ops 00:13
not for adding new ones
oh, it's just a doubly linked list
00:27 raiph joined
timotimo now it works but segfaults at the end 00:29
00:33 jnap joined 00:41 colomon joined
timotimo i think i actually made it work \o/ 00:51
01:18 jnap joined 01:35 woosley joined 01:44 FROGGS joined 02:03 benabik joined
dalek arVM/spesh_optional_args: a38ace2 | (Timo Paulssen)++ | / (4 files):
first attempt at optional positionals handling
 02:05
timotimo my work for the night
o/
02:07 colomon joined
japhb Good on ya, timotimo++ 02:08
02:21 colomon joined 03:15 colomon joined 03:27 jnap joined 04:28 jnap joined 04:52 woolfy joined 05:28 jnap joined 05:58 woolfy left 06:29 jnap joined 06:55 zakharyas joined 07:30 jnap joined 07:44 FROGGS joined
FROGGS morning 07:44
nwc10 aye, morning :-) 07:46
08:30 ashleydev joined 08:31 jnap joined
jnthn + if (req_max + 1 <= cs->num_pos && req_max + 1 + opt_max + 1 ) { 08:37
timotimo: Given the thing after the && will always be true, something must be wrong there
/* null out the third operand, the block to jump to */ 08:39
Don't actually need that either it turns out
Because it only reads as many things as ->info->num_operands tells it
09:32 jnap joined 10:17 woosley left, woosley joined 10:32 jnap joined 10:43 colomon joined
cognominal jnthn, another moarvm problem (and not specifically related to emacs terminal). Doing a grammar dump (so long outpout) and the end of the dump is not printed. Works fine when redirect to a file 11:05
So so far, output can hangs (in the REPL for lizmat), loop (REPL in a emacs, ahem, pseudo terminal), or the output can disappear altogether. 11:08
FROGGS cognominal: happens also when you dump the ast, to screen
cognominal yes
FROGGS it works when you pipe it into a file for some reason
cognominal yes
FROGGS I dunno why though :o)
cognominal the common thing is the use of a terminal 11:09
with the grammar dump it does not hang btw, just forget to print the end of the output. 11:10
what is strange is the variety of bugs probably due to linenoise. 11:11
I have not yet read that part of the code, so I will spare you a bogus hypothesis. 11:13
that I redirect to a file, or do ... | cat >file makes no difference, it dumps unto the end unlike in a terminal. 11:17
jnthn cognominal: I suspect you just have a sufficiently up to date MoarVM. 11:19
cognominal: The REPL hang got fixed and the others are likely related.
*don't have a
cognominal recompiling rakudo... 11:21
liz problem has disappeared. the REPL in emacs still loop (and eventually segfaults, I did not notice it). And a long grammar dump has its end still disappearing. On mac. 11:31
11:33 jnap joined
cognominal ho readline is not the default? I see #define MVM_HAS_READLINE 0 in config.h 11:37
not sure of the incantation to get it. 11:38
--moar-make-option='--use-readline', it seems 11:40
nope 11:45
afk. will read the backlog 11:51
FROGGS .oO( perhaps pipe the backlog to a file so it won't get truncated ) 11:52
cognominal :)
timotimo jnthn: oh yes, i apparently didn't finish that line of code :D 12:10
good thing i put it all into a branch
also, i get a bunch of spectest failures with my changes, but i have not yet diffed it against a moarvm/spesh 12:11
FROGGS is spesh already capable or running spectests without failures? 12:12
jnthn Was last time I checked 12:16
At least, nothing over nom
er, master
FROGGS cool! 12:18
:o)
good job! all of you
12:34 jnap joined
timotimo i still kind of want to do the thing where identifier in dumps of bytecode (both --dump and the spesh dump) get pretty boxes drawn next to them that have colors to correspond to the hash of their identity or something 12:36
i wonder if that'd do well at all 12:37
my changes broke trigonometry 12:48
and it seems like i get some mixin trouble which would probably be caused by the lack of deopt? 12:49
jnthn No, I don't think we're smart enough to need the deopt there yet... 12:50
timotimo oh
jnthn The trig is probably a better lead
timotimo well crud
jnthn Hopefully it's not an obtuse problem, and you'll find acute fix...
timotimo not ok 32 - 7-6i has an angle of -0.7086263 12:51
# got: -1.5707963267949
# expected: -0.7086263
moritz m: say pi * (1.5707963267949 - 0.7086263) 12:54
camelia rakudo-moar 358582: OUTPUTĀ«2.70858702232417ā¤Ā»
nwc10 m
m: say -1.5707963267949 / -0.7086263
camelia rakudo-moar 358582: OUTPUTĀ«2.21667799627942ā¤Ā»
nwc10 that's odd
m: say exp 1
camelia rakudo-moar 358582: OUTPUTĀ«2.71828182845905ā¤Ā» 12:55
nwc10 close...
timotimo turning off the spesh makes the tests pass again
so i guess i'll parse the spesh log output
13:35 jnap joined 13:55 btyler joined 14:08 jnap joined 14:10 jnap joined 14:29 benabik joined 14:34 woolfy joined 14:41 jnap1 joined 15:06 colomon joined 15:11 FROGGS[mobile] joined 15:16 brrt joined 15:21 colomon joined 15:29 lizmat joined 16:29 FROGGS joined 16:33 colomon joined 16:41 cognominal joined
FROGGS jnthn: svg-plot/t/series.t segfaults when its module is precompiled; getstaticcode gets a null object... all is fine when it is not precompiled 16:47
jnthn: if you are interested: github.com/FROGGS/frame_inc 16:56
it is test 3 there
the test 2 which segfaults is kinda funny too 16:59
17:04 colomon joined 17:19 zakharyas joined
FROGGS err, test 1 that is 18:05
timotimo jnthn: trigonometry tests fail by the dozen even without my patches 19:44
and something seems to hang 19:45
apparently 05-metasyntax/litvar.t and S05-interoplation/regex-in-variable.rakudo.moar are hanging
jnthn timotimo: Interesting... Things looked clean the last spesh spectest I did. Not sure if some later thing I added is to blame... 19:46
timotimo gist.github.com/timo/549b283dbbcab5ca6d5a ā† not really sure what's wrong there. 19:47
when i disable spesh, these are clean, fwiw
as you can see a bit earlier, the trig just gets *weird* values
now i have no clue how to debug this 19:48
the output from the spesh log is *huge*
and it's a huge amount of PHI removal
the only thing i can think of is perhaps turning decont into set causing some trouble 19:49
jnthn Well, it only does it if it knows it can
Whcih is very few times at the momet
timotimo right
but still ... what?
i guess i'll try to golf it? 19:50
hehe
jnthn Well, you could also roll back a few patches in spesh and see if it was a recent one that busted it
timotimo it's funny to see. the first 9 tests succeed
the 10th one is the first to fail :)
19:54 brrt joined
timotimo doesn't quite get it 19:58
FROGGS after eight minutes?
timotimo well, i'm digging 19:59
but i'm not hitting paydirt or anything that'd suggest there is paydirt anywhere nearby
i think i may want to parallelize the spesh_diff tool :) 20:00
though it's currently kind of limited by the time it takes to slurp up the lines and parse them 20:01
maybe i can optimize the parsing a little bit, though
perl6-m ../moarvm/tools/spesh_diff.p6 foobarlog 237,83s user 19,82s system 95% cpu 4:29,14 total 20:04
FROGGS jnthn: that segfault when we apply a trait on a sub drives me nuts 20:09
in ParametricRolwHOW.specialize the $!body_block(|@pos_args, |%named_args); gives: Could not instantiate role '<anon>': Cannot invoke null object 20:10
but I can print the body_block's name (it is &trait_mod:<is>) and the first positional arg (it is Sub+{<anon>}) 20:12
jnthn That's...a sub name, not a block name... :S
FROGGS err, body_blocks name is Sub
jnthn uh, role block name 20:13
Oh
FROGGS right, I've read my output wrongish :o)
the thing looked up in P6::World method apply_trait is &trait_mod:<is>
like in: 20:14
m: sub foo is hidden_from_backtrace { }
camelia ( no output )
FROGGS and when documenting a sub
precomp breaks it
it happens also with &trait_mod:<handles>, Sub, Attribute+{<anon>} 20:20
jnthn Well, adding an nqp::isnull guard on the thing we getstaticcode on might help
FROGGS I'm trying 20:23
I just wonder why it is null in the first place
jnthn 'cus the call to resolve never triggers, I guess 20:24
timotimo tan and atan only get a few PHIs removed from the final block, deconts turned into sets and a findmethod turned into a sp_findmethod 20:25
i can't tell what's going wrong here 20:26
jnthn Oh, I think I maybe can guess it... 20:28
oh, no.
dalek arVM/spesh_optional_args: 5724e06 | (Timo Paulssen)++ | src/spesh/args.c:
fix bogus condition, remove superfluous instruction
brrt wow... one might say this little specializer has created a flurry of activity :-) 20:34
timotimo is an excitement-driven developer :\ 20:35
FROGGS I've not done a single commit :o)
jnthn timotimo: Serialization bugs a CRAZY EXCITING!
timotimo that's true
FROGGS O.o
jnthn win! 20:36
timotimo 49k lines parsed 20:37
the rest is kinda much faster
the performance difference between just spurting out the files and then git diffing them is stunning 20:38
hm, maybe i should turn the loop with ~= "$foo\n" into an array and then a .join 20:39
FROGGS jnthn: -.-
jnthn FROGGS: Did the nqp::isnull I suggested help? 20:40
FROGGS jnthn: I really expected that you would say "nah, that only hides the problem" when I would add a check like that there
jnthn: I mean the good thing is: almost all modules pass and no build problems anymore on moar 20:42
jnthn FROGGS: It...sorta does, but I can cope with it.
FROGGS that works for me :o)
jnthn FROGGS: Because a different solution needs me to think really hard about it.
FROGGS k
that makes it unlikely for me to get a patch within a reasonable timeframe
jnthn And it's a real pain right now because we have 3 different closure models to cope with.
FROGGS (like "April")
jnthn So I'm happy with the null-check workaround for the time being. 20:43
I can go for a real fix when giving the JVM the Moar closure semantics.
FROGGS only DBIish fails some tests now 20:44
jnthn How about the hang?
FROGGS I am going to spectest that now
jnthn: does not hang anymore
jnthn And works?
FROGGS yes
jnthn wow 20:45
FROGGS yeah
I double checked that I dont see parrot's output
though I guess we need to fiddle with panda to make it work right, I think it picks up my system rakudo and would otherwise fail because it won't find a perl6-* in path 20:46
that is where we need a proper $*EXECUTABLE for before and after installation
timotimo hmm 20:52
i've partially parallelized the spesh log and now it finishes by dumping core 20:53
jnthn But...it finishes? :)
timotimo yeah 20:55
i couldn't get a timing, though
i fear i only got it up to 110% cpu usage at most
do you expect the hotness detection will stay a simple counter like currently? 20:57
and if so, what number do you suppose will be what we end up with?
having a fixed number would mean we'll end up specializing every single routine in the whole system for all long running processes that even barely touch them 20:58
jnthn That's kinda OK though
timotimo i suppose
jnthn The more interesting thing is to factor in code size
timotimo at some point our specializer will give a much bigger payoff
jnthn Which is a rough indicator of "how much effort do I have to put in" 20:59
timotimo ah, that's a good point
how easy is it to estimate code size before we construct the ssa and cfg?
do we have that value somewhere handy already?
jnthn easy.
bytecode_length hangs off the sf
timotimo sounds good; but it's much too early to be doing that
at the moment we'll benefit from trying to specialize every single thing, so we find bugs more easily 21:00
jnthn yeah, I pondered a MVM_SPESH_ALL envvar also :) 21:01
timotimo MVM_SPESH_CRAZY? 21:02
jnthn MVM_SPESH_MAYBE
timotimo MVM_SPESH_ME_MAYBE?
jnthn "You called me just once, and this is crazy, I'm in debug mode, so spesh me maybe..." 21:03
timotimo hrm 21:11
this wasn't really worth it:
Command terminated by signal 6
299.48user 29.45system 5:43.41elapsed 95%CPU (0avgtext+0avgdata 815464maxresident)k 21:12
dalek arVM/spesh: 803afb2 | (Timo Paulssen)++ | tools/spesh_diff.p6:
output kind of a status display, hopefully help performance.
 21:15
timotimo jnthn: what'd be the next thing i could have a stab at? with regards to specialization? 21:16
dalek arVM/spesh: a38ace2 | (Timo Paulssen)++ | / (4 files):
first attempt at optional positionals handling
 21:19
arVM/spesh: 5724e06 | (Timo Paulssen)++ | src/spesh/args.c:
fix bogus condition, remove superfluous instruction
arVM/spesh: ec053df | (Timo Paulssen)++ | / (4 files):
Merge branch 'spesh_optional_args' into spesh

this specializes code based upon whether or not individual optional arguments have been passed or not.
jnthn timotimo: Not sure if we can immediately hit it in non-contrived cases, but istype may in some cases be statically resolvable 21:20
timotimo oh, that does sound good
do we have something like dead code elimination?
as in: if a block is not referenced, it won't be emitted back out?
jnthn Not yet
That's not too bad to do 21:21
timotimo well, and i'm not sure if we turn a conditional jump based upon a specialize-time-constant into an unconditional jump
hm.
jnthn Yes, we should do that
but your "arg provided" path should already be making at least one block unreachable.
timotimo ah, yes
so if a BB has a goto in it that's followed by any number of instructions and then the "this block logically follows" piece of information 21:22
that goto could be removed and the "block that logically follows" could be replaced
will that mess up the resulting bytecode somehow?
jnthn That's not the right way really
timotimo OK, how should i approach it? 21:23
jnthn When you add the goto unconditional, you should remove the linear_next from the successor's list
timotimo can i just remove that?
jnthn I'd write a "remove successor" in manipulate.c
timotimo set it to null?
jnthn And it should also go and find the pred pointer.
And clear that too
Well, not just null it
It you have two successors a NULL leaves a hole 21:24
Which isn't good
timotimo oh!
jnthn So it's a little more work.
timotimo right, i can just splice it then
jnthn But important is to remove the pred too
Anyway, *then* as a final step after all the other optimizations, you walk the graph for things that have no pred and iterate to a fixed point.
timotimo right; the pred of the succ is an array of pointers to BBs and i can just go through the list, find which one equals the bb i'm manipulating and splice that out of the list, too?
jnthn There's already some code that does that in the graph building stage. 21:25
Right.
timotimo ah, but the graph building stage is "too early"
could that code be factored out reasonably?
jnthn right, but we do it there so the rpo sort isn't a mess
It probably could be.
timotimo i can have a look at that
that should be a decent chunk of work
and the removed blocks should show up nicely in the diffs
the signature of remove_successor should take the block to change and the exact successor to remove, right? 21:26
should i touch linear_next at all? 21:27
hmm. 21:29
there should probably be a bit of constant propagation at specialize time if we want the istype thing to really shine
otherwise there'll be a gap between istype and the dead code elimination still 21:30
as i think usages of istype look like "put the result in a register" and then "jump conditionally on that register"
but it may well have a bunch of logical ops applied to it
luckily, we're in SSA, so that should be easy-ish
jnthn timotimo: No, don't touch linear_next 21:39
timotimo: oh, not when you do remove_successor 21:40
timotimo: Yes, constant propagation is very possible
timotimo: The facts infrastructure is kinda about that
timotimo not what when i do remove_successor?
jnthn I mean, the final cleanup of the graph to really remove unreachable things will fiddle with linear_net 21:41
But your remove_successor function should not.
timotimo ah
good, that clears things up a bit
jnthn I hate networks.
timotimo as in ... ethernet and wifi?
and hotel wifi in particular?
jnthn yeah, and especially VMs and bridging 21:42
No, a network for tomorrow's course...
Got it to work
timotimo oh
jnthn Bu tnot sure why it din't "just work" like it did when we tested things a week or so ago...
timotimo that stuff interests me, but i do recognize that it's pretty hard much of the time
21:46 btyler joined
timotimo jnthn: i don't have to care about the order of succ entries, right? 21:49
jnthn no, just find the one you want if it it's not the last one then shuffle ones after it to fill the hole 21:50
timotimo i could either shuffle all following entries or do the two-finger compaction trick :P 21:51
well, it'll be fine
jnthn to be honest, normally there'll be, like, 1. 21:52
timotimo ah
fair enough :)
what did the line req_pos_ins[i]->operands[1].lit_i16 = (MVMint16)i; do, btw? 21:58
jnthn Set the argument to grab 21:59
timotimo i didn't put something equivalent into the optional parameter piece
jnthn o.O 22:00
timotimo but i'd imagine it'd have to be (req_max + i) in that case?
jnthn I...dunno how it can possibly work then :)
yeah, it's the index into the args buffer
timotimo OK
timotimo reinstates that line
dalek arVM/spesh: d6bd28c | (Timo Paulssen)++ | src/spesh/args.c:
this line apparently was correct.
 22:02
arVM/spesh: c4eb1c3 | (Timo Paulssen)++ | src/spesh/manipulate. (2 files):
a manipulation function to remove a successor from a BB
jnthn Need to sleep here...teaching tomorrow
'night
FROGGS gnight
timotimo gnite jnthn 22:03
22:03 colomon joined
timotimo oh! constant propagation combined with the fact system could probably give a nice specialization when default values are assumed for arguments 22:07
jnthn: if i reinstate that line, i get segfaults when running optimized things 22:11
caused by, no surprises here, a sp_getarg_o operation
- checkarity liti16(0), liti16(1) 22:28
- param_op_o r0(1), liti16(0), BB(3)
- Successors: 3, 2
+ sp_getarg_o r0(1), liti16(0)
+ goto BB(3)
+ Successors: 3
- Predeccessors: 1
+ Predeccessors:
i'm still confused why removing that line would make things not work; it would seem like it would be necessary 22:30
the fact that i can compile a working rakudo without the line and get segfaults almost immediately if i have it in ... 22:31
if i put it in without the req_max +, it doesn't segfault, but that would give me the values of the required arguments, not the optional ones :\ 22:33
maybe MVM_op_sp_getarg_* can't operate on optionals any way 22:34
it does seem to work, from a little test 22:35
gist.github.com/timo/127e3654005b70b92de5 - here's a successor and predecessor pair getting removed in two cases :) 22:43
22:45 bcode joined
dalek arVM/spesh: 0a4ca4a | (Timo Paulssen)++ | src/spesh/args.c:
the previous ought to have been wrong i think.
 22:46
arVM/spesh: e675f07 | (Timo Paulssen)++ | src/spesh/args.c:
debug output revealed, this line is actually superfluous

  ..?!?
arVM/spesh: f5fb940 | (Timo Paulssen)++ | src/spesh/manipulate.c:
don't forget to change num_succ and num_pred
arVM/spesh: bfa263c | (Timo Paulssen)++ | src/spesh/args.c:
remove successors of BBs where we put or remove gotos.
timotimo eliminate_dead seems to already be factored out from all the rest 22:53
oh, but that does re-numbering 22:56
that could possibly be problematic, as the post-order and dominance calc rely on that?
it *may* be that these numbers are only necessary once during the construction of all these things and can then safely be mangled 23:00
but who knows?
i'll just TIAS
huh. i wonder if i'd have to remove the blocks from the dominance children list, too 23:04
unfortunately i don't even know what exactly the dominance information conveys/stores/...
- Dominance children: 2, 3 23:06
+ Dominance children: 2, 2
well, this is a red flag anyways
i don't know what i'm doing. hopefully jnthn will come in and fix my crap tomorrow :D 23:17
dalek arVM/spesh: 04ca1d8 | (Timo Paulssen)++ | tools/spesh_diff.p6:
precedence messed up the matcher. Mouq++
 23:29
arVM/spesh: e5fe385 | (Timo Paulssen)++ | src/spesh/ (2 files):
c&p eliminate_dead, remove children in addition to succ.
timotimo if you actually want to run things, you may need to comment out a few things? it's pretty hard to tell what exactly breaks what and what doesn't and what already was ...
i think i'll go to bed and see if i can get something up and running for istype tomorrow 23:48
23:49 btyler joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!