github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:45 sivoais left 00:48 sivoais joined 05:33 Ven`` joined 05:42 Ven`` left 07:18 brrt joined
brrt \o 07:54
nwc10 o/ 07:59
08:27 Ven`` joined, Ven`` left 09:08 zakharyas joined 09:18 brrt left 09:30 brrt joined 09:40 yoleaux left
jnthn o/ 10:09
nwc10 \o 10:10
10:24 brrt left, brrt joined 10:31 scovit left 10:34 brrt left 10:37 brrt joined
brrt the problem I debugged yesterday (the one that appeared in the optimizer), I'm going to deem the 'missing ancestor problem' 10:43
and this specific instance is the eliminated ancestor problem 10:44
this problem is:
- if there is a expression tree that has multiple branches, and there is a value referenced in either of them, then it must be defined (reified) in an 'ancestor' of those branches 10:48
if that value *isn't* reified before the branches, then one of the branches gets the value and the other does not
in this case, the original template does have the value reified (in the condition) but that reification is eliminated, which means that the first reference is in the branch, leaving the second reference with a garbage value 10:49
so... I'm guessing the wrongness here is the dependency on the ancestral definition in the first place
what I'm not very sure of, yet, is how to fix it
10:57 brrt left
lizmat hopes that R#2704 is now easily fixable by jnthn 11:01
synopsebot R#2704 [open]: github.com/rakudo/rakudo/issues/2704 [regression][⚠ blocker ⚠] Does not fail with spesh disabled, fails 100% with MVM_SPESH_BLOCKING 11:02
12:05 brrt joined 12:09 zakharyas left 12:27 brrt left 12:55 lucasb joined
dogbert11 lizmat: have you tried with MVM_SPESH_INLINE_DISABLE=1 ? 12:59
jnthn I just have and that hides it 13:05
dogbert11 jnthn: I can confirm that the commit of interest should be github.com/rakudo/rakudo/commit/eb...2c4dbcd9b2 13:08
13:12 AlexDani` joined 13:14 AlexDaniel left
jnthn It's not interesting, though. 13:17
I mean, it's not a spesh change, so all it means is "that commit caused a code-gen change that exposed an existing problem" 13:18
13:19 AlexDani` is now known as AlexDaniel
masak kind of like a bug wrangler does 13:20
dogbert11 I should perhaps note that on eb3917c the error msg shows up immediately and is: Invocant of method 'match' must be a type object of type 'Any', not an object instance of type 'Concatenation'. Did you forget a 'multi'? 13:21
turning on spesh here does NOT help 13:22
*off
jnthn Deopt one requested by interpreter in frame 'to-lines' (cuid '17') 13:23
Will deopt 364 -> 258
Resolved offset 364 to deopt index 58
Materialized a Scalar
Materialized a Str
Recreated frame 'modifier-to-string' (cuid '12')
Completed deopt_one in 'modifier-to-string' (cuid '12') with potential uninlining
That happens just before it goes wrong 13:24
I'm guessing the VMNull comes from a deopt gone bad
Ah, and MVM_SPESH_PEA_DISABLE=1 also seems to hide the problem, though I was sure I'd tried that earlier and it didn't...wonder if I typo'd it or something 13:27
dogbert11 makes a note of the new debug flag
jnthn Unfortunately, PEA + deopt = probably difficult 13:30
13:32 zakharyas joined
Geth MoarVM/expr-jit-invoke: 47e4518249 | (Bart Wiegmans)++ | 4 files
[JIT] Implement invoke sequence in expr JIT
 13:33
MoarVM/expr-jit-invoke: 34a17b9207 | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Eliminate special consume_invoke opcode

Except for nativecall_invoke, we no longer need this part of the legacy JIT.
MoarVM/expr-jit-invoke: 00575bd853 | (Bart Wiegmans)++ | 7 files
[JIT] WIP on nativeinvoke in the expression JIT
13:40 brrt joined
dogbert11 jnthn: did some bisecting of you pea branch in MoarVM. The last good commit is github.com/MoarVM/MoarVM/commit/16...18e3cfd69e 14:08
jnthn bah, hard to find, but utterly silly... 14:09
dogbert11 so you found it :) 14:10
jnthn Seems so. Almost ashamed to push it :P
dogbert11 haha
masak :) 14:11
Geth MoarVM: 04982f6e9c | (Jonathan Worthington)++ | src/spesh/inline.c
Fix thinko in merge of materialization tables

During inlining, we always copied the registers from the first entry in the materializations table, not the current one we should have been looking at.		 14:12
masak oops ;)
I almost feel like some static linting tool could have piped up and said "you know you're not _using_ `i` at all, right?" 14:14
jnthn Yeah, quite possibly
Heck, if I did my MoarVM coding in CLion rather than Vim it might well have caught it :)
Maybe I should be using that :) 14:15
masak yeah, now I'm curious whether CLion would've caught it... :)
dogbert11 another poor blocker eliminated
jnthn masak: It does highlight such unused things in IntelliJ, so quite possibly 14:17
masak hm, "highlight" as in turn grey. more like "lowlight"... 14:18
jnthn :P 14:26
timotimo: github.com/MoarVM/MoarVM/commit/ef...8975cf38c2 causes github.com/rakudo/rakudo/issues/2703 14:27
Even with MVM_JIT_DISABLE=1 set 14:29
And indeed, commenting out the second hunk of the patch makes no difference; it really is the swapping of the order of the fields 14:31
14:32 brrt left
jnthn timotimo: False alarm; the module actually its doing .WHERE and then poking into MoarVM REPR internals! 14:37
I'll gladly break things that do that. 14:38
Updated relevant tickets, and opened an issue on the module in question. 14:49
dogbert11 can't be many blockers left now 14:50
jnthn Maybe github.com/rakudo/rakudo/issues/2706 14:51
timotimo oooh! right! we do have those NativeHelpers 14:53
yeah, i didn't think of them when i changed that
jnthn Well, we shouldn't really have to think of things outside of MoarVM when we do such changes. 14:59
This won't be the only change of that nature that we'll want to do
timotimo aye 15:02
we could at least point them out to the module authors so they can have some detection code
jnthn Yes, in the issue I opened on the module I suggested version detection code, but also noted that we should try and make it so such trickery isn't required. 15:03
timotimo aye
i still haven't actually put any reviewing work in to bring the CStructArray PR closer to being merged 15:04
jnthn Yeah, I think that'd help
timotimo so NativeHelpers::Blob should be implementable by "just" making CStruct support vmarray, and i guess semantics of "always copy the size the vmarray had before from the pointer that is now there" when refreshing the CStruct after a native call 15:08
but damn, that sounds slow
15:11 zakharyas left
jnthn .tell brrt Looking into github.com/rakudo/rakudo/issues/2706 but it seems to be a JIT bug 15:12
aww, no bot
timotimo: Ah, possibly ^ is of interest to you also 15:13
Oh, I should check it's not using NativeHelpers::Blob before going any futher I guess 15:14
No, it ain't
But it's fine at 2eab275df145c58c269220fe and not at HEAD 15:15
d626337bea9ea752fcf is bad also 15:16
215430c4db7 is good 15:17
It's efdf568975cf38c2 15:19
And commeting out the JIT part of that patch fixes it 15:20
timotimo: Any ideas? 15:22
I don't immediately see why it'd be wrong 15:23
On the other hand I'm not totally familiar with this bit of the cdoe 15:24
*code
15:27 zakharyas joined
timotimo if the cstruct arg isn't in the last position of that signature, it's possible putting support for cstructs actually unhid something 15:28
jnthn Didn't figure out what sig it is yet
Valgrind has nothing to say
Almost every method in there has a CStruct argument 15:30
So it could be pretty much any of them 15:31
timotimo in theory we could have a global counter that counts down and at 0 it always fails at CStruct 15:32
gotta go! 15:33
jnthn We have a loop like this: 15:35
while $glyph-idx {
$!struct.FT_Load_Glyph( $glyph-idx, $flags );
&code($glyph);
$glyph.char-code = $!struct.FT_Get_Next_Char( $glyph.char-code, $glyph-idx);
}
And
method FT_Get_Next_Char(
FT_ULong $char-code,
FT_UInt $agindex is rw )
returns FT_ULong is native(FT-LIB) {*};
I wonder if it's about that `is rw` arg there
dogbert11 Red seems to use NativeHelpers, i.e R#2665 15:37
synopsebot R#2665 [open]: github.com/rakudo/rakudo/issues/2665 [⚠ blocker ⚠] MoarVM panic when testing Red
jnthn dogbert11: Yeah, I already figured that's just a case of the same 15:38
Commenting out `case MVM_NATIVECALL_ARG_UINT` in that JIT switch also helps
As does adding `if (is_rw) goto fail;` for the int cases 15:39
15:40 zakharyas1 joined, zakharyas left
jnthn I also notice it uses MVM_JIT_ARG_I64_RW for all of them 15:45
nine: If you've a moment at some point to look, github.com/rakudo/rakudo/issues/2706 seems to be a nativecall JIT bug, but mostly that adding CStruct support there has exposed an existing problem 15:48
At some point it just starts returning the same value endlessly, which makes me think the rw isn't w'ing :) 15:50
15:50 zakharyas1 left
jnthn Alas, I don't have time to dig in right now to figure out why. 15:50
dogbert11 arg_type = dst == -1 15:52
? is_rw ? MVM_JIT_ARG_I64_RW : MVM_JIT_ARG_I64
: is_rw ? MVM_JIT_PARAM_I64_RW : MVM_JIT_PARAM_I64;
I must admit I don't understand that construct
lizmat arg_type = (dst == -1 .... ) perhaps better ? 15:53
dogbert11 yeah, helps a bit I guess 15:54
jnthn It does also seem sensitive to inlining 15:55
OK, I'm out of time for now 15:57
Plus I suspect one of brrt++ or nine++ could figure it out faster than I can anyway
16:08 zakharyas joined 16:45 MasterDuke left 16:47 zakharyas1 joined 16:50 zakharyas left 17:06 zakharyas1 left
timotimo twitter.com/johnregehr/status/1097...5982355456 - oh wow 18:40
20:05 lucasb left
jnthn Yowser, interesting. 22:19

Powered by Cro and the Raku® Programming Language.

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

Thank you!