01:16 nativecallable6 joined 01:17 unicodable6 joined, quotable6 joined 02:18 FROGGS joined 02:23 Kaiepi joined 02:27 Kaiepi joined 03:02 ilbot3 joined 03:57 bloatable6 joined 04:33 Kaiepi joined 05:42 lizmat joined 06:58 domidumont joined 07:06 domidumont joined 07:44 domidumont joined 08:36 zakharyas joined 08:47 zakharyas1 joined 09:12 zakharyas joined 10:11 zakharyas joined 10:12 brrt joined
jnthn morning o/ 10:25
Geth MoarVM/jit-expr-optimizer: a79867b920 | (Bart Wiegmans)++ | 4 files
Move label assignment to tiler

Branches internal to the expression tree are implemented using dynamically assigned labels that are allocated after all 'graph' labels (for objects and instructions). Prior to this patch, labels were assigned to nodes (using the info structure) during the tree analysis phase of tree construction. ... (21 more lines)		 10:33
10:41 AlexDaniel joined
jnthn Hm, with HEAD of everything and spesh stressing enabled, I can't reproduce a crash in stage parse of Rakudo. 11:06
(That's with no local patches)
Gets through fine with just MVM_SPESH_BLOCKING=1 but not NODELAY too 11:07
jnthn tries without any of those just in case
Huh, *then* it shows up 11:08
wat
That means it will be nearly impossible to debug. 11:09
Yup, goes away with any of the debugging tools 11:10
11:15 brrt joined
brrt morning jnthn 11:16
jnthn o/ brrt
brrt jnthn, do you think it is a spesh / JIT bug? 11:19
jnthn Certainly a spesh bug
I got it to dump the spesh graph on such a crash
brrt ehm. do you think it is amenable to spesh bisect?
jnthn No because it goes away under _BLOCKING
And without that LIMIT is meaningless 11:20
It is at least a small sub that gets broken
brrt oh, darn 11:21
jnthn And I can see how a recent change would have made it optimizable in a way that it wasn't before
It removes one branch of a conditional that contains a try
Somehow, it doesn't stick it into the unreachable handlers array
And the FH_START gets left around
Without the END or GOTO 11:22
brrt is it expr JIT sensitivie? 11:23
jnthn No 11:24
It's something going wrong in dead BB elimination
brrt aha
well, unfortunatley, i know nothing about that, or 'very little'
jnthn Well, I understand why the FH_START moves. I don't understand why the FH_GOTO is lost. 11:25
dogbert2_ wasn't nine speaking about GOTO's a few days ago? 11:31
jnthn I think that was goto instructions, this is handler target addresses
dogbert2_ irclog.perlgeek.de/moarvm/2018-01-07#i_15661477 11:32
just found it
though I should mention it just in case
jnthn Thanks :)
Trying to get it to dump, just for this method, the outcome of each stage of dead BB elimination
To see if I can spot what/how it messes up 11:33
oh. At that point it's "correct" (silly, but correct) 11:34
BB 46 (0x7f785697d330): 11:35
line: 3615 (pc 1286)
Instructions:
[Annotation: FH Start (0)]
[Annotation: FH Goto (0)]
[Annotation: FH End (0)]
takehandlerresult r3(1)
It's shuffled the lot of them together
If that were making it to the code-gen it'd just produce an harmless but impossible handler in the table 11:36
So, now to find what trashes it 11:37
It's fine after the last pass of dead BB elimination 11:38
That doesn't leave any likely candidates. Hopefully will soon have it narrowed to a particular step 11:40
eliminate_unused_log_guards(tc, g); 11:42
eliminate_pointless_gotos(tc, g);
eliminate_dead_ins(tc, g);
One of those 3 must be doing it
Kaiepi do you guys have any tips working with gfb? 11:43
11:46 committable6 joined
jnthn huh, apparently eliminate_unused_log_guards is to blame?! 11:46
Kaiepi: gfb? 11:47
Kaiepi gdb
i'm kinda tired
jnthn gdb in general, or for debugging MoarVM stuff? 11:48
Kaiepi moarvm
jnthn timotimo wrote some gdb plugin to help in various cases 11:49
It's in the MoarVM repo somewhere
Kaiepi nice, thanks
jnthn Otherwise, p MVM_dump_backtrace(tc) in a frame where tc is available lets one get a dump of the stack from a "what code MoarVM is running" perspective
If chasing a GC bug then turn on MVM_GC_DEBUG=1 and there's an extra function compiled in that can try to find a pointer in all the nurseries and gen2 pages 11:50
p MVM_utf8_encode_C_string(tc, foo) lets you display an MVMString * 11:51
Those are the things I use most often
Kaiepi i think there could be a memory bug invaled in what i'm looking at heree 11:58
Geth MoarVM: c1da6f9688 | (Jonathan Worthington)++ | 3 files
Make instruction deletion within dead BBs a no-op

Otherwise, annotation motion can become confused in various ways. The work would also be a waste of time, as the instruction is already dead by virtue of its enclosing BB being dead.		 12:11
jnthn That addresses the issue 12:14
dogbert2_ cool
jnthn Lunch now, then I guess I've got the not_i thing I was doing yesterday to debug
Yeah, this fix doesn't help it at all. That woulda been lucky 12:15
bbiab
12:24 nebuchadnezzar joined 13:28 jsimonet joined 13:41 zakharyas joined 13:57 AlexDaniel joined 14:10 brrt joined
MasterDuke jnthn: fwiw, c1da6f9688 did not fix the segv when building nqp if moarvm was built with --valgrind 15:18
however, doing some additional debugging, moarvm built with --optimize=0 and --valgrind is fine 15:19
jnthn I didn't even know that issue existed; I'd be surprised if it changed anything 15:27
oh heck, I think I see what's breaking the not_i opt 15:28
yeah 15:30
There's a comment reading
/* This is a bit naughty with regards to the SSA form, but
* we'll hopefully get away with it
Guess what? We don't really.
That's probably the issue, anyway 15:31
timotimo that sounds like something i would have done
jnthn Probably :P
Now trying to figure out why it's naugty and what to do about it
It's the isfalse spesh that inserts a not_i that's breaking fwiw 15:32
m: my $i = 1111111111111111111111111111111111111111111111111111111111111; my $a = 0; loop { $a += ?$i } 15:34
camelia (timeout)
jnthn Oh, maybe it constant folds it
Oh no, it's in a var
Ah, and I guess the code under case MVM_BOOL_MODE_UNBOX_INT doesn't apply to Perl 6 (big) Int, perhaps 15:35
I don't actually see the SSA issue still 15:37
But
- /* If there's a known value, update the fact. */
- if (res_facts->flags & MVM_SPESH_FACT_KNOWN_VALUE)
- res_facts->value.i = !res_facts->value.i;
That seems very dubious
timotimo oh, yes 15:38
jnthn And removing it seems to help
I don't know that we do violate the SSA form here; we obtain a temp register and put a result into that, and then do a not_i from that to the original target register 15:39
And temp registers play well with SSA form
And we're only assigning the result register once
Can you remember why you thought it did break it? 15:40
timotimo hm, could it be i changed the code since i wrote that comment? 15:41
jnthn Maybe :)
There's a - /* If there's a known value, update the fact. */ 15:42
- if (res_facts->flags & MVM_SPESH_FACT_KNOWN_VALUE)
- res_facts->value.i = !res_facts->value.i;
gah
There's a MVM_BOOL_MODE_BIGINT
That could maybe also be handy to implement here
timotimo at the time i wrote that comment, the fact update wasn't there yet 15:43
15:43 zakharyas joined
jnthn The fact update is the broked part though, I think 15:44
And it's not really useful
Not with a not_i opt in place
The optimize_is_concrete will, if possible, set the known value property on temp 15:45
The not_i opt will then see it and optimize away the not_i if possible
MasterDuke github.com/MoarVM/MoarVM/issues/779 for the segv with --valgrind, also includes a link to some backtraces 15:46
timotimo i'm operating off of 1% sleep spread out over ~12 hours of lying in bed right now :\ 15:48
jnthn Ah, that's really not a good condition for answering spesh questions 15:49
Or for much of anything really
Geth MoarVM: 38a7f57711 | (Jonathan Worthington)++ | src/spesh/optimize.c
Remove bogus comment and known value fact tweak

The comment seems wrong or perhaps just outdated because the code got fixed; the temp registers play fine with SSA form and there is still one use of the original register and one write to the final destination one, so all's good. The known value fact update code, on the other hand, was rather dubious; it should probably have been looking at the temp facts and setting the res facts. However, with an upcoming not_i optimization about to be added, that will take care of things more elegantly, so just remove it.		 15:58
MoarVM: 671bf1dbf9 | (Jonathan Worthington)++ | src/spesh/optimize.c
Add some missing fact dependencies
MoarVM: ed7c1234f4 | (Jonathan Worthington)++ | src/spesh/optimize.c
Optimize not_i when its input is a known value

Can simply turn it into a constant then. This in turn means that we can optimize Foo:U in Perl 6 signatures away completely; previously, the isconcrete/not_i sequence blocked this being optimized out, and thus left some asesrtparamcheck instructions in, which would block inlining.
16:00 zakharyas joined
dogbert2_ what kind of gains can be expected from this fix? 16:09
timotimo now anything with a Foo:U signature can now be inlined if it's small enough
for example, the auto-viv candidates for positional/associative access
(i just regurgitated this info from liz and jnthn) 16:10
jnthn my %h; %h{$word}++ will be able to have that ++ op inlined for example 16:11
Oh, well, it's not quite that simple :)
As likely that will be a mix of undefined and defined :)
16:12 squashable6 joined
jnthn But it'll still be less signature checking code :) 16:12
dogbert2_ every bit counts :-) 16:15
16:39 brrt joined
brrt rebase coming up 16:50
Geth MoarVM/jit-expr-optimizer: 14 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/a...295a2b334b		 16:51
17:06 zakharyas joined
brrt any particular reason why MVM_reg_uint types start at 16 and up 17:19
oh, i see
17:23 coverable6 joined, benchable6 joined 17:39 bisectable6 joined 18:00 Kaiepi joined 19:39 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Add some missing fact dependencies' 19:39
travis-ci.org/MoarVM/MoarVM/builds/327741504 github.com/MoarVM/MoarVM/compare/c...1bf1dbf980
19:39 travis-ci left, greppable6 joined 19:54 Ven`` joined 20:15 zakharyas joined
Geth MoarVM/jit-expr-optimizer: dce091807d | (Bart Wiegmans)++ | src/jit/expr.c
Remove check_template from expr JIT

Since we now have better checks in the expression compiler, this is redundant and wasteful. More importantly I want to change the representation of the expression nodes and these checks will then be wrong.		 20:48
20:59 evalable6 joined 21:11 bart_ joined 21:22 Kaiepi joined, zakharyas joined 21:52 Kaiepi joined 22:09 samcv joined 22:11 bart_ joined 22:32 statisfiable6 joined, releasable6 joined, reportable6 joined 22:51 greppable6 joined 23:02 Kaiepi 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!