Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-04-02

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 timotimo hum.
00:04 timotimo i turn the param_op_o into a goto and the BB link is correct
00:04 timotimo but the first ten invokes of my method say "hello", the rest say ""
00:05 timotimo haha, i seem to have exactly confused passed and non-passed
00:06 timotimo hm, no, not quite
00:09 timotimo the first 10 invocations are okay, the rest are wrong
00:09 timotimo 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"
00:10 timotimo oh, i have to *drop* the operation
00:11 timotimo ah, if the thing was set it will write and jump
00:11 timotimo i had that exactly backwards
00:13 timotimo but there's only a manipulate function for deleting ops
00:13 timotimo not for adding new ones
00:13 timotimo oh, it's just a doubly linked list
00:27 raiph joined #moarvm
00:29 timotimo now it works but segfaults at the end
00:33 jnap joined #moarvm
00:41 colomon joined #moarvm
00:51 timotimo i think i actually made it work \o/
01:18 jnap joined #moarvm
01:35 woosley joined #moarvm
01:44 FROGGS joined #moarvm
02:03 benabik joined #moarvm
02:05 dalek MoarVM/spesh_optional_args: a38ace2 | (Timo Paulssen)++ | / (4 files):
02:05 dalek MoarVM/spesh_optional_args: first attempt at optional positionals handling
02:05 dalek MoarVM/spesh_optional_args: review: https://github.com/MoarVM/MoarVM/commit/a38ace21a2
02:05 timotimo my work for the night
02:05 timotimo o/
02:07 colomon joined #moarvm
02:08 japhb Good on ya, timotimo++
02:21 colomon joined #moarvm
03:15 colomon joined #moarvm
03:27 jnap joined #moarvm
04:28 jnap joined #moarvm
04:52 woolfy joined #moarvm
05:28 jnap joined #moarvm
05:58 woolfy left #moarvm
06:29 jnap joined #moarvm
06:55 zakharyas joined #moarvm
07:30 jnap joined #moarvm
07:44 FROGGS joined #moarvm
07:44 FROGGS morning
07:46 nwc10 aye, morning :-)
08:30 ashleydev joined #moarvm
08:31 jnap joined #moarvm
08:37 jnthn +    if (req_max + 1 <= cs->num_pos && req_max + 1 + opt_max + 1 ) {
08:37 jnthn timotimo: Given the thing after the && will always be true, something must be wrong there
08:39 jnthn /* null out the third operand, the block to jump to */
08:39 jnthn Don't actually need that either it turns out
08:39 jnthn Because it only reads as many things as ->info->num_operands tells it
09:32 jnap joined #moarvm
10:17 woosley left #moarvm
10:17 woosley joined #moarvm
10:32 jnap joined #moarvm
10:43 colomon joined #moarvm
11:05 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:08 cognominal 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
11:08 cognominal yes
11:08 FROGGS it works when you pipe it into a file for some reason
11:08 cognominal yes
11:08 FROGGS I dunno why though :o)
11:09 cognominal the common thing is the use of a terminal
11:10 cognominal with the grammar dump it does not hang btw, just forget to print the end of the output.
11:11 cognominal what is strange is the variety of bugs probably due to linenoise.
11:13 cognominal I have not yet read that part of the code, so I will spare you a  bogus hypothesis.
11:17 cognominal that I redirect to a file, or do ... | cat >file    makes no difference, it dumps unto the end unlike in a terminal.
11:19 jnthn cognominal: I suspect you just have a sufficiently up to date MoarVM.
11:19 jnthn cognominal: The REPL hang got fixed and the others are likely related.
11:19 jnthn *don't have a
11:21 cognominal recompiling rakudo...
11:31 cognominal 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:33 jnap joined #moarvm
11:37 cognominal ho readline is not the default?  I see #define MVM_HAS_READLINE 0 in config.h
11:38 cognominal not sure of the incantation to get it.
11:40 cognominal --moar-make-option='--use-readline', it seems
11:45 cognominal nope
11:51 cognominal afk. will read the backlog
11:52 * FROGGS .oO( perhaps pipe the backlog to a file so it won't get truncated )
11:52 cognominal :)
12:10 timotimo jnthn: oh yes, i apparently didn't finish that line of code :D
12:10 timotimo good thing i put it all into a branch
12:11 timotimo also, i get a bunch of spectest failures with my changes, but i have not yet diffed it against a moarvm/spesh
12:12 FROGGS is spesh already capable or running spectests without failures?
12:16 jnthn Was last time I checked
12:16 jnthn At least, nothing over nom
12:16 jnthn er, master
12:18 FROGGS cool!
12:18 FROGGS :o)
12:18 FROGGS good job! all of you
12:34 jnap joined #moarvm
12:36 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:37 timotimo i wonder if that'd do well at all
12:48 timotimo my changes broke trigonometry
12:49 timotimo and it seems like i get some mixin trouble which would probably be caused by the lack of deopt?
12:50 jnthn No, I don't think we're smart enough to need the deopt there yet...
12:50 timotimo oh
12:50 jnthn The trig is probably a better lead
12:50 timotimo well crud
12:50 jnthn Hopefully it's not an obtuse problem, and you'll find acute fix...
12:51 timotimo not ok 32 - 7-6i has an angle of -0.7086263
12:51 timotimo # got:      -1.5707963267949
12:51 timotimo # expected: -0.7086263
12:54 moritz m: say pi * (1.5707963267949 - 0.7086263)
12:54 camelia rakudo-moar 358582: OUTPUT«2.70858702232417␤»
12:54 nwc10 m
12:54 nwc10 m: say -1.5707963267949 /  -0.7086263
12:54 camelia rakudo-moar 358582: OUTPUT«2.21667799627942␤»
12:54 nwc10 that's odd
12:54 nwc10 m: say exp 1
12:55 camelia rakudo-moar 358582: OUTPUT«2.71828182845905␤»
12:55 nwc10 close...
12:55 timotimo turning off the spesh makes the tests pass again
12:55 timotimo so i guess i'll parse the spesh log output
13:35 jnap joined #moarvm
13:55 btyler joined #moarvm
14:08 jnap joined #moarvm
14:10 jnap joined #moarvm
14:29 benabik joined #moarvm
14:34 woolfy joined #moarvm
14:41 jnap1 joined #moarvm
15:06 colomon joined #moarvm
15:11 FROGGS[mobile] joined #moarvm
15:16 brrt joined #moarvm
15:21 colomon joined #moarvm
15:29 lizmat joined #moarvm
16:29 FROGGS joined #moarvm
16:33 colomon joined #moarvm
16:41 cognominal joined #moarvm
16:47 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:56 FROGGS jnthn: if you are interested: https://github.com/FROGGS/frame_inc
16:56 FROGGS it is test 3 there
16:59 FROGGS the test 2 which segfaults is kinda funny too
17:04 colomon joined #moarvm
17:19 zakharyas joined #moarvm
18:05 FROGGS err, test 1 that is
19:44 timotimo jnthn: trigonometry tests fail by the dozen even without my patches
19:45 timotimo and something seems to hang
19:45 timotimo apparently 05-metasyntax/litvar.t and S05-interoplation/regex-in-variable.rakudo.moar are hanging
19:46 jnthn timotimo: Interesting... Things looked clean the last spesh spectest I did. Not sure if some later thing I added is to blame...
19:47 timotimo https://gist.github.com/timo/549b283dbbcab5ca6d5a ← not really sure what's wrong there.
19:47 timotimo when i disable spesh, these are clean, fwiw
19:47 timotimo as you can see a bit earlier, the trig just gets *weird* values
19:48 timotimo now i have no clue how to debug this
19:48 timotimo the output from the spesh log is *huge*
19:48 timotimo and it's a huge amount of PHI removal
19:49 timotimo 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
19:49 jnthn Whcih is very few times at the momet
19:49 timotimo right
19:49 timotimo but still ... what?
19:50 timotimo i guess i'll try to golf it?
19:50 timotimo hehe
19:50 jnthn Well, you could also roll back a few patches in spesh and see if it was a recent one that busted it
19:50 timotimo it's funny to see. the first 9 tests succeed
19:50 timotimo the 10th one is the first to fail :)
19:54 brrt joined #moarvm
19:58 * timotimo doesn't quite get it
19:58 FROGGS after eight minutes?
19:59 timotimo well, i'm digging
19:59 timotimo but i'm not hitting paydirt or anything that'd suggest there is paydirt anywhere nearby
20:00 timotimo i think i may want to parallelize the spesh_diff tool :)
20:01 timotimo though it's currently kind of limited by the time it takes to slurp up the lines and parse them
20:01 timotimo maybe i can optimize the parsing a little bit, though
20:04 timotimo perl6-m ../moarvm/tools/spesh_diff.p6 foobarlog  237,83s user 19,82s system 95% cpu 4:29,14 total
20:09 FROGGS jnthn: that segfault when we apply a trait on a sub drives me nuts
20:10 FROGGS in ParametricRolwHOW.specialize the $!body_block(|@pos_args, |%named_args); gives: Could not instantiate role '<anon>': Cannot invoke null object
20:12 FROGGS 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
20:12 FROGGS err, body_blocks name is Sub
20:13 jnthn uh, role block name
20:13 jnthn Oh
20:13 FROGGS right, I've read my output wrongish :o)
20:13 FROGGS the thing looked up in P6::World method apply_trait is &trait_mod:<is>
20:14 FROGGS like in:
20:14 FROGGS m: sub foo is hidden_from_backtrace { }
20:14 camelia rakudo-moar 358582: ( no output )
20:14 FROGGS and when documenting a sub
20:14 FROGGS precomp breaks it
20:20 FROGGS 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
20:23 FROGGS I'm trying
20:23 FROGGS I just wonder why it is null in the first place
20:24 jnthn 'cus the call to resolve never triggers, I guess
20:25 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:26 timotimo i can't tell what's going wrong here
20:28 jnthn Oh, I think I maybe can guess it...
20:28 jnthn oh, no.
20:28 dalek MoarVM/spesh_optional_args: 5724e06 | (Timo Paulssen)++ | src/spesh/args.c:
20:28 dalek MoarVM/spesh_optional_args: fix bogus condition, remove superfluous instruction
20:28 dalek MoarVM/spesh_optional_args: review: https://github.com/MoarVM/MoarVM/commit/5724e061c9
20:34 brrt wow... one might say this little specializer has created a flurry of activity :-)
20:35 * timotimo is an excitement-driven developer :\
20:35 FROGGS I've not done a single commit :o)
20:35 jnthn timotimo: Serialization bugs a CRAZY EXCITING!
20:35 timotimo that's true
20:35 FROGGS O.o
20:36 jnthn win!
20:37 timotimo 49k lines parsed
20:37 timotimo the rest is kinda much faster
20:38 timotimo the performance difference between just spurting out the files and then git diffing them is stunning
20:39 timotimo hm, maybe i should turn the loop with ~= "$foo\n" into an array and then a .join
20:39 FROGGS jnthn: -.-
20:40 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
20:42 FROGGS 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.
20:42 FROGGS that works for me :o)
20:42 jnthn FROGGS: Because a different solution needs me to think really hard about it.
20:42 FROGGS k
20:42 FROGGS that makes it unlikely for me to get a patch within a reasonable timeframe
20:42 jnthn And it's a real pain right now because we have 3 different closure models to cope with.
20:42 FROGGS (like "April")
20:43 jnthn So I'm happy with the null-check workaround for the time being.
20:43 jnthn I can go for a real fix when giving the JVM the Moar closure semantics.
20:44 FROGGS only DBIish fails some tests now
20:44 jnthn How about the hang?
20:44 FROGGS I am going to spectest that now
20:44 FROGGS jnthn: does not hang anymore
20:44 jnthn And works?
20:44 FROGGS yes
20:45 jnthn wow
20:45 FROGGS yeah
20:45 FROGGS I double checked that I dont see parrot's output
20:46 FROGGS 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 FROGGS that is where we need a proper $*EXECUTABLE for before and after installation
20:52 timotimo hmm
20:53 timotimo i've partially parallelized the spesh log and now it finishes by dumping core
20:53 jnthn But...it finishes? :)
20:55 timotimo yeah
20:55 timotimo i couldn't get a timing, though
20:55 timotimo i fear i only got it up to 110% cpu usage at most
20:57 timotimo do you expect the hotness detection will stay a simple counter like currently?
20:57 timotimo and if so, what number do you suppose will be what we end up with?
20:58 timotimo 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
20:58 timotimo i suppose
20:58 jnthn The more interesting thing is to factor in code size
20:58 timotimo at some point our specializer will give a much bigger payoff
20:59 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
20:59 timotimo how easy is it to estimate code size before we construct the ssa and cfg?
20:59 timotimo do we have that value somewhere handy already?
20:59 jnthn easy.
20:59 jnthn bytecode_length hangs off the sf
20:59 timotimo sounds good; but it's much too early to be doing that
21:00 timotimo at the moment we'll benefit from trying to specialize every single thing, so we find bugs more easily
21:01 jnthn yeah, I pondered a MVM_SPESH_ALL envvar also :)
21:02 timotimo MVM_SPESH_CRAZY?
21:02 jnthn MVM_SPESH_MAYBE
21:02 timotimo MVM_SPESH_ME_MAYBE?
21:03 jnthn "You called me just once, and this is crazy, I'm in debug mode, so spesh me maybe..."
21:11 timotimo hrm
21:11 timotimo this wasn't really worth it:
21:11 timotimo Command terminated by signal 6
21:12 timotimo 299.48user 29.45system 5:43.41elapsed 95%CPU (0avgtext+0avgdata 815464maxresident)k
21:15 dalek MoarVM/spesh: 803afb2 | (Timo Paulssen)++ | tools/spesh_diff.p6:
21:15 dalek MoarVM/spesh: output kind of a status display, hopefully help performance.
21:15 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/803afb2ba9
21:16 timotimo jnthn: what'd be the next thing i could have a stab at? with regards to specialization?
21:19 dalek MoarVM/spesh: a38ace2 | (Timo Paulssen)++ | / (4 files):
21:19 dalek MoarVM/spesh: first attempt at optional positionals handling
21:19 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/a38ace21a2
21:19 dalek MoarVM/spesh: 5724e06 | (Timo Paulssen)++ | src/spesh/args.c:
21:19 dalek MoarVM/spesh: fix bogus condition, remove superfluous instruction
21:19 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/5724e061c9
21:19 dalek MoarVM/spesh: ec053df | (Timo Paulssen)++ | / (4 files):
21:19 dalek MoarVM/spesh: Merge branch 'spesh_optional_args' into spesh
21:19 dalek MoarVM/spesh:
21:19 dalek MoarVM/spesh: this specializes code based upon whether or not individual
21:19 dalek MoarVM/spesh: optional arguments have been passed or not.
21:19 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/ec053dfebf
21:20 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
21:20 timotimo do we have something like dead code elimination?
21:20 timotimo as in: if a block is not referenced, it won't be emitted back out?
21:20 jnthn Not yet
21:21 jnthn 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
21:21 timotimo hm.
21:21 jnthn Yes, we should do that
21:21 jnthn but your "arg provided" path should already be making at least one block unreachable.
21:21 timotimo ah, yes
21:22 timotimo 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 timotimo that goto could be removed and the "block that logically follows" could be replaced
21:22 timotimo will that mess up the resulting bytecode somehow?
21:22 jnthn That's not the right way really
21:23 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
21:23 timotimo can i just remove that?
21:23 jnthn I'd write a "remove successor" in manipulate.c
21:23 timotimo set it to null?
21:23 jnthn And it should also go and find the pred pointer.
21:23 jnthn And clear that too
21:23 jnthn Well, not just null it
21:24 jnthn It you have two successors a NULL leaves a hole
21:24 jnthn Which isn't good
21:24 timotimo oh!
21:24 jnthn So it's a little more work.
21:24 timotimo right, i can just splice it then
21:24 jnthn But important is to remove the pred too
21:24 jnthn 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.
21:24 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?
21:25 jnthn There's already some code that does that in the graph building stage.
21:25 jnthn Right.
21:25 timotimo ah, but the graph building stage is "too early"
21:25 timotimo could that code be factored out reasonably?
21:25 jnthn right, but we do it there so the rpo sort isn't a mess
21:25 jnthn It probably could be.
21:25 timotimo i can have a look at that
21:25 timotimo that should be a decent chunk of work
21:25 timotimo and the removed blocks should show up nicely in the diffs
21:26 timotimo the signature of remove_successor should take the block to change and the exact successor to remove, right?
21:27 timotimo should i touch linear_next at all?
21:29 timotimo hmm.
21:29 timotimo there should probably be a bit of constant propagation at specialize time if we want the istype thing to really shine
21:30 timotimo otherwise there'll be a gap between istype and the dead code elimination still
21:30 timotimo as i think usages of istype look like "put the result in a register" and then "jump conditionally on that register"
21:30 timotimo but it may well have a bunch of logical ops applied to it
21:30 timotimo luckily, we're in SSA, so that should be easy-ish
21:39 jnthn timotimo: No, don't touch linear_next
21:40 jnthn timotimo: oh, not when you do remove_successor
21:40 jnthn timotimo: Yes, constant propagation is very possible
21:40 jnthn timotimo: The facts infrastructure is kinda about that
21:40 timotimo not what when i do remove_successor?
21:41 jnthn I mean, the final cleanup of the graph to really remove unreachable things will fiddle with linear_net
21:41 jnthn But your remove_successor function should not.
21:41 timotimo ah
21:41 timotimo good, that clears things up a bit
21:41 jnthn I hate networks.
21:41 timotimo as in ... ethernet and wifi?
21:41 timotimo and hotel wifi in particular?
21:42 jnthn yeah, and especially VMs and bridging
21:42 jnthn No, a network for tomorrow's course...
21:42 jnthn Got it to work
21:42 timotimo oh
21:42 jnthn Bu tnot sure why it din't "just work" like it did when we tested things a week or so ago...
21:42 timotimo that stuff interests me, but i do recognize that it's pretty hard much of the time
21:46 btyler joined #moarvm
21:49 timotimo jnthn: i don't have to care about the order of succ entries, right?
21:50 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:51 timotimo i could either shuffle all following entries or do the two-finger compaction trick :P
21:51 timotimo well, it'll be fine
21:52 jnthn to be honest, normally there'll be, like, 1.
21:52 timotimo ah
21:52 timotimo fair enough :)
21:58 timotimo what did the line req_pos_ins[i]->operands[1].lit_i16 = (MVMint16)i; do, btw?
21:59 jnthn Set the argument to grab
21:59 timotimo i didn't put something equivalent into the optional parameter piece
22:00 jnthn o.O
22:00 timotimo but i'd imagine it'd have to be (req_max + i) in that case?
22:00 jnthn I...dunno how it can possibly work then :)
22:00 jnthn yeah, it's the index into the args buffer
22:00 timotimo OK
22:00 * timotimo reinstates that line
22:02 dalek MoarVM/spesh: d6bd28c | (Timo Paulssen)++ | src/spesh/args.c:
22:02 dalek MoarVM/spesh: this line apparently was correct.
22:02 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/d6bd28cb9e
22:02 dalek MoarVM/spesh: c4eb1c3 | (Timo Paulssen)++ | src/spesh/manipulate. (2 files):
22:02 dalek MoarVM/spesh: a manipulation function to remove a successor from a BB
22:02 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/c4eb1c3191
22:02 jnthn Need to sleep here...teaching tomorrow
22:02 jnthn 'night
22:02 FROGGS gnight
22:03 timotimo gnite jnthn
22:03 colomon joined #moarvm
22:07 timotimo oh! constant propagation combined with the fact system could probably give a nice specialization when default values are assumed for arguments
22:11 timotimo jnthn: if i reinstate that line, i get segfaults when running optimized things
22:11 timotimo caused by, no surprises here, a sp_getarg_o operation
22:28 timotimo -      checkarity liti16(0), liti16(1)
22:28 timotimo -      param_op_o r0(1), liti16(0), BB(3)
22:28 timotimo -    Successors: 3, 2
22:28 timotimo +      sp_getarg_o r0(1), liti16(0)
22:28 timotimo +      goto BB(3)
22:28 timotimo +    Successors: 3
22:28 timotimo -    Predeccessors: 1
22:28 timotimo +    Predeccessors:
22:30 timotimo i'm still confused why removing that line would make things not work; it would seem like it would be necessary
22:31 timotimo the fact that i can compile a working rakudo without the line and get segfaults almost immediately if i have it in ...
22:33 timotimo 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:34 timotimo maybe MVM_op_sp_getarg_* can't operate on optionals any way
22:35 timotimo it does seem to work, from a little test
22:43 timotimo https://gist.github.com/timo/127e3654005b70b92de5 - here's a successor and predecessor pair getting removed in two cases :)
22:45 bcode joined #moarvm
22:46 dalek MoarVM/spesh: 0a4ca4a | (Timo Paulssen)++ | src/spesh/args.c:
22:46 dalek MoarVM/spesh: the previous ought to have been wrong i think.
22:46 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/0a4ca4a28d
22:46 dalek MoarVM/spesh: e675f07 | (Timo Paulssen)++ | src/spesh/args.c:
22:46 dalek MoarVM/spesh: debug output revealed, this line is actually superfluous
22:46 dalek MoarVM/spesh:
22:46 dalek MoarVM/spesh: ..?!?
22:46 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/e675f07b6b
22:46 dalek MoarVM/spesh: f5fb940 | (Timo Paulssen)++ | src/spesh/manipulate.c:
22:46 dalek MoarVM/spesh: don't forget to change num_succ and num_pred
22:46 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/f5fb940f1c
22:46 dalek MoarVM/spesh: bfa263c | (Timo Paulssen)++ | src/spesh/args.c:
22:46 dalek MoarVM/spesh: remove successors of BBs where we put or remove gotos.
22:46 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/bfa263c212
22:53 timotimo eliminate_dead seems to already be factored out from all the rest
22:56 timotimo oh, but that does re-numbering
22:56 timotimo that could possibly be problematic, as the post-order and dominance calc rely on that?
23:00 timotimo 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 timotimo but who knows?
23:00 timotimo i'll just TIAS
23:04 timotimo huh. i wonder if i'd have to remove the blocks from the dominance children list, too
23:04 timotimo unfortunately i don't even know what exactly the dominance information conveys/stores/...
23:06 timotimo -    Dominance children: 2, 3
23:06 timotimo +    Dominance children: 2, 2
23:06 timotimo well, this is a red flag anyways
23:17 timotimo i don't know what i'm doing. hopefully jnthn will come in and fix my crap tomorrow :D
23:29 dalek MoarVM/spesh: 04ca1d8 | (Timo Paulssen)++ | tools/spesh_diff.p6:
23:29 dalek MoarVM/spesh: precedence messed up the matcher. Mouq++
23:29 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/04ca1d84f6
23:29 dalek MoarVM/spesh: e5fe385 | (Timo Paulssen)++ | src/spesh/ (2 files):
23:29 dalek MoarVM/spesh: c&p eliminate_dead, remove children in addition to succ.
23:29 dalek MoarVM/spesh: review: https://github.com/MoarVM/MoarVM/commit/e5fe385c30
23:29 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 ...
23:48 timotimo i think i'll go to bed and see if i can get something up and running for istype tomorrow
23:49 btyler joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary