|
01:33
japhb left
01:46
Kaiepi joined
02:32
Kaiepi left
02:33
Kaiepi joined
02:59
lizmat left
06:00
Geth left
06:01
dalek joined,
Geth joined,
p6lert joined,
synopsebot_ joined
|
|||
| Geth | MoarVM: eed6fbb312 | (Samantha McVey)++ | src/core/interp.c Put interp.c in the same order as the oplist |
06:39 | |
| MoarVM: samcv++ created pull request #873: Add more expr JIT ops |
06:42 | ||
| samcv | if someone can take a look at that pull request ^ this is my first time adding things with the expression jit engine | ||
|
07:06
lizmat joined
08:18
robertle joined
08:59
robertle left
09:40
lizmat left
09:49
lizmat joined
10:41
dogbert2 left
10:50
dogbert2 joined
11:34
SourceBaby joined
12:16
Util joined
12:22
zakharyas joined
12:33
robertle joined
12:40
zakharyas left
12:53
domidumont joined
13:00
domidumont left
13:01
domidumont joined
13:06
domidumont left
|
|||
| timotimo | FWIW, hack died again last night. afl isn't really interested in resuming existing runs, so this is where that ends. | 13:50 | |
| moritz | :( | 14:00 | |
| timotimo | no big deal, the nqp fuzzing kind of led nowhere, i just didn't have the heart to stop it ;) | 14:01 | |
|
14:09
MasterDuke left,
MasterDuke joined
|
|||
| dogbert17 | I have a moronic question. What's the correct way to run Rakudo on an older nqp revision? Just building an older nqp and installing it in the Rakudo install directory doesn't seem to be the correct way to do this. | 14:30 | |
| jnthn | Hm, I think it is, though you'd need to re-compile Rakudo too? | 14:31 | |
| dogbert17 | things go south if I do that with 'perl Configure.pl --gen-moar --gen-nqp --backends=moar' followed by make, nqp is rebuilt with the latest version then | 14:33 | |
| perhaps I shouldn't use the nqp which is created in the Rakudo directory fot stuff like this | |||
| jnthn | Ah, the --gen-nqp is the problem | 14:35 | |
| Remove that and --gen-moar and then provide --prefix=/path/to/install | |||
| That said, you can also I think do --gen-nqp=sha1 | |||
| dogbert17 | cool, I'll try | ||
| jnthn | Where the sha1 is the NQP build you want | ||
| dogbert17 | interesting, I'll definitely try that. Perhaps I'm attacking this all wrong but I want to find which nqp commit broke the (s)printf tests | 14:36 | |
| nine | I wonder why we create such bad code as: gist.github.com/niner/d6e718fe499a...c705627d45 | 14:39 | |
| Shouldn't this just become "create r14(4), r14(3)" or am I missing something? | 14:40 | ||
| jnthn | It'd normally kill of the p6decontrv, I'm guessing it doesn't know the type of r27? | 14:41 | |
| In the create | 14:42 | ||
| Also, note that we don't actually create such bad code. That's what we're left over with after gutting numerous other things :) | |||
| I suspect many `set` instructions live on due to over-conservative deopt tracking | 14:43 | ||
| We don't yet have enough information to decrement any usage counts that we bumped for the sake of deopt | 14:44 | ||
| takedispatcher could be eliminated over inlines, we just didn't do that yet | |||
|
14:44
AlexDani` joined
|
|||
| jnthn | Ah, and it's not quite trivial to do it either | 14:45 | |
| nine | So in which cases would it be ok to remove an inlined takedispatcher? | ||
| jnthn | Um | ||
| Actually it's quite hard to say :( | |||
| Because takedispatcher checks if a dispatcher was set for this frame | |||
| Well, this block | |||
|
14:45
AlexDaniel left
|
|||
| jnthn | And so we can't actualy figure it out by looking at what we're inlining into | 14:45 | |
| I remember this now. I once thought "ah, we can toss those out easily" | 14:46 | ||
| And it turns out...not really. | |||
| I'm a bit bothered by the way we deal with callsame and friends in general, though. It's quite hard to optimize. | 14:47 | ||
| The design pre-dates having anything like spesh, so wasn't really done with that in mind. | |||
| It also uses one of the hairiest Rakudo ext-ops | 14:48 | ||
| nine | Intriguing: it seems to know the type passed to the create, but doesn't know the resulting type. | ||
| jnthn | Huh, that's odd | ||
| The facts logic should always propagate that | |||
| And I thought we ran the facts analysis on inlinees now | |||
| Oh hurrah, finally some rain here | 14:49 | ||
| nine | We actually do | ||
|
14:49
AlexDani` is now known as AlexDaniel
|
|||
| AlexDaniel | dogbert17: actually I attempted something similar yesterday and faced similar issues | 14:50 | |
| nine | Also I'm talking about the original spesh of the to be inlined function: gist.github.com/niner/19b131d9e803...160b75364e | ||
| AlexDaniel | for me, doing `git checkout 2018.05`, `make realclean` and then the regular Configure stuff doesn't work | ||
| I'm not sure which files are left behind, or something… | |||
| nine | Of the "create r4(2), r0(2)", r0(2) has KnTyp while r4(2) doesn't | 14:51 | |
| jnthn | nine: Do you have the before? | ||
| Or rather, can you gist the before? | |||
| I'm curious what the original code from | |||
| s/from/was | 14:52 | ||
| Maybe we produced the `create` | |||
| AlexDaniel | dogbert17: fwiw whateverable builds from a completely clean state, so it is more reliable when it comes to questions like this… | ||
| so I guess if I ever attempt to bisect something locally I'll do exactly that :S | |||
| nine | jnthn: sure, that's the whole thing: gist.github.com/niner/22d119087d65...e42eba0af8 | ||
| jnthn | Hmm | 14:54 | |
| Odd | |||
| Nothing stands out as to why it'd not be propagating the type. github.com/MoarVM/MoarVM/blob/mast...acts.c#L30 should be doing it | 14:55 | ||
| dogbert17 | AlexDaniel: so what's, in your opinion, the best way to find the borked nqp commit | 14:56 | |
| nine | It just behaves as if MVM_SPESH_FACT_KNOWN_TYPE wasn't set in type_facts->flags | ||
| jnthn | Maybe it wasn't for some reason | ||
| AlexDaniel | dogbert17: have a `git bisect start` in a separate nqp folder, use it for guidance (it will tell you which commits to test). Then wipe your rakudo directory, clone freshly and build | 14:57 | |
| jnthn | nine: Either way, we could probably make sure to try and propagate it at the point we optimize create in optimize.c | 14:58 | |
| nine | Because.... it wasn't known at the time of the fact discovery. It became known by way of optimizing the decont into a set | ||
| AlexDaniel | dogbert17: simply change the revision in NQP_REVISION, that is known to work | ||
| jnthn | nine: Aha. | 14:59 | |
| nine: A little surprised it didn't manage to track that at facts time, still | |||
| nine | That's at least my best guess | ||
| jnthn | Anyway, there's nothing to stop us, when seeing a create in optimize.c, setting the result type | ||
| dogbert17 | AlexDaniel: I'll experiment a bit with what you and jnthn have told me | 15:03 | |
| AlexDaniel | dogbert17: the downside with my method is that with my poor internet connection it will spend most of the time just cloning the repos | 15:04 | |
| I guess a better way is to teach make realclean to actually clean, dammit. But this will only improve bisects in the future | 15:05 | ||
| dogbert17 | things gets very tricky when Rakudo, nqp and moarvm have to change at the same time | 15:16 | |
| AlexDaniel | dogbert17: in this case it's easier because you don't have to worry about moarvm | 15:23 | |
| dogbert17: maybe we should put some effort into this: github.com/perl6/whateverable/issues/40 | 15:25 | ||
| dogbert17: I can actually give you a step-by-step guide on how to implement this, if you're interested | |||
| nine | jnthn: except that it ends up in all sorts of weird errors... | 15:28 | |
| dogbert17 | I'm beginning to suspect github.com/perl6/nqp/commit/d743c0...d7601b6627 as the cause of the test failures. | 15:31 | |
| nine | dogbert17: I don't like it anyway :) | 15:33 | |
| dogbert17 | :) | 15:35 | |
| MasterDuke | nqp::elems is faster though | 15:37 | |
| dogbert17 | perhaps there's a tiny typo somewhere in that large commit | 15:39 | |
|
15:39
domidumont joined
|
|||
| AlexDaniel | dogbert17: so reverting it makes the issue go away? | 15:44 | |
| nine | MasterDuke: may be, but I'm pretty sure, rewriting the stuff in C would make it faster still. Doesn't mean it's the way to go. | ||
| AlexDaniel | I think this line is incorrect: github.com/perl6/nqp/commit/d743c0...47f3601L41 | 15:45 | |
| but it's irrelevant to the problem | |||
| dogbert17 | I'm now 99% certain that d743c0f88d is the culprit | ||
| nine | With the commit reverted, spectest passes | 15:46 | |
| AlexDaniel | nine: what about sprintf("%d-%s", 42) | 15:47 | |
| what's the output? | |||
| nine | Your printf-style directives specify 2 arguments, but 1 argument was supplied | ||
| AlexDaniel | right | 15:48 | |
| well, there were changes to sprintf: github.com/perl6/nqp/commit/d743c0...fc7b218053 | 15:52 | ||
| but I see nothing wrong there | |||
| (btw the line I mentioned before is fine, but why .t files were touched at all is still a good question…) | 15:55 | ||
| timotimo continues the test case minimization with afl | |||
| MasterDuke | timotimo: you are getting ones you can repro? | 15:56 | |
| timotimo | well, those are the moarvm files, they are reliable | ||
| tmin is useful for making the input files simpler | |||
| it usually makes them about 10% smaller, but more importantly replaces vast sections with just the ascii digit 0 over and over | |||
| so you can more easily figure out what parts of the input make the crash be a crash | 15:57 | ||
| these minimized files won't --dump correctly any more, of course | |||
| nine | Rain! | 15:58 | |
| jnthn | Really much rain...we had to close the windows because the strong wind was blowing it all indoors too | 16:00 | |
| nine | MasterDuke: same effect as that huge commit (including errors) could be had by adding a single line of code in src/NQP/Optimizer.nqp:293: $op.op('elems'); | 16:04 | |
| MasterDuke | huh, don't think i've ever looked at NQP's optimizer | 16:06 | |
| any ideas what causes those errors though? | 16:07 | ||
| nine | yep | 16:12 | |
| MasterDuke | fixable? | ||
| nine | trivial | 16:13 | |
| src/core/Exception.pm6:2043: change num to int | |||
| It's because unary + is 'numify' and will return a num while nqp::elems returns an int | 16:14 | ||
| MasterDuke | nine speaks the truth. adding that line to the NQP optimizer makes +@ as fast as nqp::elems in NQP and after changing that type in Exception.pm6 rakudo passes a spectest | 16:32 | |
| does someone who has a rakudo commit bit want to make the change or should i PR it? | 16:34 | ||
|
16:40
zakharyas joined
|
|||
| timotimo | watch out for problems with the jvm there, though | 16:44 | |
| just a weak hunch | 16:47 | ||
| native types and the jvm sometimes don't mix as easily as on moarvm | |||
|
16:58
zakharyas left
16:59
zakharyas joined
|
|||
| MasterDuke | nine, dogbert17: idle curiosity, but how long does stage parse take for the jvm rakudo build with your ryzens? | 17:09 | |
| 200s for me | 17:13 | ||
|
18:00
camelia left
18:02
bartolin_ joined
18:03
jsimonet1 joined
18:04
bartolin left,
camelia joined,
mst__ joined,
mst left,
mst__ is now known as mst,
mst left,
mst joined,
ChanServ sets mode: +o mst
18:35
zakharyas left
18:37
zakharyas joined
18:38
zakharyas left
18:40
zakharyas joined
|
|||
| nine | MasterDuke: I've been too impatient to build on JVM for a very long time | 18:45 | |
| MasterDuke | yeah, i can't do it regularly | 19:00 | |
|
19:10
zakharyas left,
zakharyas1 joined
19:12
zakharyas joined
19:14
zakharyas2 joined,
zakharyas1 left
19:17
zakharyas left
19:19
domidumont left
19:23
zakharyas2 left
19:27
lizmat left
19:32
zakharyas joined
19:37
zakharyas left
19:38
zakharyas joined
19:49
lizmat joined
20:30
Kaiepi left,
Kaiepi joined
20:35
ilmari[m] joined
21:14
wictory[m] joined,
AlexDaniel`` joined
21:28
Kaiepi left,
Kaiepi joined
22:04
zakharyas left
23:46
robertle left
|
|||