github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:55 japhb left, japhb_ joined 01:05 Kaiepi joined 01:30 japhb_ left 01:32 japhb joined 01:34 lucasb left 01:48 MasterDuke left 02:51 japhb left 02:53 japhb joined 04:08 sivoais joined
nwc10 good *, #moarvm 06:52
real RISCV, or emulated? The gcc farm is faking it, IIRC
nine Good question! I couldn't find any official description. But on build.opensuse.org/monitor one can switch the display of what the workers are working on from "Package-name" to "Architecture" and that shows that x86_64 servers are building the riscv64 packages. 07:08
A nice side effect of using the OBS is that the command line client osc also supports local build. That runs in a chroot environment or a KVM or for cross platform development qemu VM. And it will gladly give you access to this VM. 07:15
nwc10 aha. gcc compile farm is shell access, and then "the rest is up to you" 07:16
annoyingly the Mips hardware is basically routers, and only has 2G, so can't build rakudo for mips64 07:17
it can for mips32
NQP is OK on mips64
nine So getting a debug environment can be as simple as osc build --vm-type=qemu --vm-telnet=23 --vm-memory=1024 --vm-disk-size=4096 openSUSE_Factory_RISCV riscv64
Sadly, no. I don't see a MIPS distribution in the list 07:18
At least not on the build service instance run by the SUSE folks. The software is free and ready made appliances are available. I don't know how hard it would be to add e.g. a Debian MIPS to the list. The OBS does support Debian. 07:24
nwc10 It's OK. The mips hardwar is enough to be confident that most portability bugs are found 07:25
nine I guess the most important bit is having a big endian machine. Which we do with ppc64 07:26
nwc10 sparc64 is more fun. Stricter alignment requirements. Unfortunately all three (four?) gcc compiler farm machines are sparc64, and there doesn't seem to be a reliable way to fake up a 32 bit ABI build of our various dependencies 07:48
I made tea! Without fail! 07:49
nine Great way to start the day :) 07:56
08:08 linkable6 left 08:11 linkable6 joined 08:28 MasterDuke joined 08:36 linkable6 left 08:38 linkable6 joined
nine I am reasonably sure that the unisearch failure is a deoptimization issue 09:23
We're missing a Deopt point materialization mapping and that seems to be significant 09:24
lizmat and reducing deopts was the purpose of the decont logging PR 09:25
so after reverting that, we have more deopts again
nine I'll have some breakfast and then have a look at where these materialization mappings come from. 09:26
It's a remarkable conincidence that when trying the example I was on an unrelated branch that just so happens to also hide the issue again, so I could get two spesh logs to compare. 09:27
09:28 domidumont joined
MasterDuke nine: nice, you think a fix for this might reduce the cost of the additional decont logging? 09:33
nine No, this is strictly about correctness. But at least there's hope that there's a single reason behind the 3 spesh related issues I'm working on. All 3 (return-in-tap.t, cur-candidates.t and unisearch) share the characteristics that somehow an unexpected type appears where it shouldn't. 09:42
That would take a huge load off my shoulders 09:43
10:07 patrickb joined
nine Oh, materialization is a PEA thing, and indeed disabling PEA fixes unisearch 10:23
Sadly that means that Type check failed in binding to parameter '$bytes'; expected Blob but got Supplier::Preserving (Supplier::Preserving...) has a different cause as I do get that with PEA disabled as well 10:24
patrickb good *ning o/ 10:27
is it possible, that github.com/croservices/cro-http/issues/128 is just another instance of the spesh bug nine and MasterDuke currently hunt? 10:28
nine patrickb: can you try the various MVM_*_DISABLE options? 10:31
Intruiging: in the case where we propagate the facts for eliminated guards, PEA actually does NOT do the 1 optimization it does in the breaking case 10:32
patrickb turning of spesh fixes it. What other DISABLES are there?
nine moar --help 10:33
patrickb does as told
nine just learned that even our advanced developers are not all aware of these environment variables... Gotta keep that in mind 10:34
patrickb have to leave. I'll report back later. 11:03
11:03 patrickb left
nine I wonder why the spesh log shows deopt and materialization indexes and register numbers from the original inlinee instead of the numbers those end up with. And I don't mean "why did the developer decide to do so" but "why do I get those numbers when my reading of the code suggests I should get the other versions" 11:14
The spesh dumper goes through the spesh graph's deopt mappings and those should really contain the adjusted indexes/register numbers
And now I wonder why I thought that. It's clearly showing the correct values. 11:30
nine gets some caffeine resupply
dogbert17 caffeine solves many problems 11:44
tried running the jit bisect tool, the result file, which is quite long, mentions "Specialization of 'sequential-map'" 11:47
at least it is consistent, always the same frame 11:52
nine By now I'm sure that my facts propagation commit does not fix the issue but hide it. The mechanism is simply that with these facts we can do optimizations the old fashioned way that otherwise PEA would have to do. No PEA, no bug. 11:53
dogbert17 sounds like progress 11:56
PEA: considering frame 'type_check' (306) 12:07
PEA: partial escape analysis not implemented for loops
PEA: considering frame 'decontrv_plugin' (248)
PEA: considering frame 'assign-scalar-no-whence-no-typecheck' (182)
Type check failed in binding to parameter '<anon>'; expected Cool but got Method (proto method fc (Coo...)
didn't know that PEA had a logging mechanism 12:08
nine I can make the bug go away by either disabling PEA on cuid 2117 or by preventing inlining of cuid 2117. Looks like strong evidence that there's something wrong with (un)inlining of frames that PEA did optimizations on. But then, why does an MVM_SPESH_LIMIT hitting exactly this frame still break? 12:14
Shouldn't the spesh limit prevent the PEA optimized frame from getting inlined?
But then, the results are actually not consistent. It sometimes passes, sometimes not. And now I also get a different frame. 12:17
Wait...didn't someone point out that the test script is somehow incorrect?
dogbert17 I believe that lizmat was sceptical towards hyper calls plus writing to an array 12:20
"the code is wrong: multiple threads should *not* be writing to $sieve at the same time" - lizmat 12:21
nine Ah, yes, removing the hypers makes it more consistent. And it still shows the same oddity. 12:28
Probably because inlining isn't important. It just changes the situations in which we deopt 12:59
It comes down to at deopt idx 61 we ought to materialize a Str into r15 and we simply don't. We only do that at idx 28. 13:00
13:05 frost-lab joined
nine The reason seems to be a missing usage entry 13:12
MasterDuke that sounds like a simple fix... 13:13
nine If not for the not so simple step of finding the place where we ought to add it 13:14
13:17 domidumont left
nine [Annotation: INS Deopt Inline (idx 8 -> pc 146; line 35)] 13:24
sp_guardconc r1(6), r1(5), sslot(1), litui32(8)
sp_getspeshslot r5(1), sslot(24)
sp_get_o r7(3), r1(6), liti16(40)
[Annotation: INS Deopt Inline (idx 41 -> pc 162; line 35)]
sp_guardconc r7(4), r7(3), sslot(0), litui32(41)
[Annotation: INS Deopt Inline (idx 10 -> pc 162; line 35)]
This is part of the inlinee. We're deopting at idx 41 (61 after inlining). The interesting part here is that at idx 8 and idx 10, i.e. before and after the point we have deopt usage entries for r4. But not at idx 41. 13:25
The numbering indicates that this deopt index is different from the surrounding ones. Probably added later. The question now is: where exactly? 13:26
MasterDuke are the numbers consistent? can you just break when idx == 41? 13:28
nine Oooh.... looking at the spesh log for where that inlined candidate got created I see an additional annotation on that line: [Annotation: INS Deopt Synth (idx 10)] 13:29
So it's deopt idx 41 but should pretend to be idx 10, which would get us the usage information. But for some reason that annotation is no longer there when we inline that frame 13:30
timotimo As Timo Samsa woke one morning from uneasy dreams he found himself transformed into some rubbery ducky 13:42
13:47 MasterDuke left 13:55 MasterDuke joined
nine timotimo: that's....deep! Which really just means "I have no idea what you just said" 13:59
sena_kun always thought he was "Zamza" 14:01
calling him "Samsa" kind of ruins it. :(
MasterDuke from kafka's 'the metamorphosis', opening line i think 14:02
timotimo that's right 14:07
nine I think I now have a complete picture of what happens with this bug.
While obviously these synth deopt annotations are really important, we neither write them to the generated bytecode, read them from bytecode when creating graphs for inlining, nor would we inline them if we had done so. 14:08
MasterDuke but somehow we've only just now noticed this problem? huh 14:11
nine Well it's only a problem if we happen to deoptimize at one of these synth points in an inlined basic block. That said, this may still be behind a number of strange issues 14:14
14:19 lucasb joined
nine Aha...the deopt annotations are not actually part of the byte code. They are kept with a spesh cand 14:25
14:40 frost-lab left 15:13 zakharyas joined 15:32 Kaeipi joined, Kaiepi left 15:33 Kaeipi left 15:34 Kaeipi joined
nine Got it! 15:53
dogbert17 impressive
nine It's in no way a pushable fix, but it shows that my understanding is correct and that the bug can be fixed by retaining those synthetic deopt points. 15:56
lizmat feels a bit weird to me that deopt annotations are *not* part of the byte code ?
nine The sad news is that the issue is unrelated to the other spesh issues I'm investigating :/ 15:59
lizmat meh... sometimes you can not two birds with one stone 16:02
* :-)
.u cat 16:03
unicodable6 lizmat, U+00AA FEMININE ORDINAL INDICATOR [Lo] (ĀŖ)
lizmat, U+00BA MASCULINE ORDINAL INDICATOR [Lo] (Āŗ)
lizmat, 84 characters in total: gist.github.com/76b42a0a8b1747810f...ca5d1f7e8e
lizmat .u love
unicodable6 lizmat, U+1F340 FOUR LEAF CLOVER [So] (šŸ€)
lizmat, U+1F3E9 LOVE HOTEL [So] (šŸ©)
lizmat, 6 characters in total (šŸ€šŸ©šŸ’ŒšŸ¤ŸšŸ„ŠšŸ§¤): gist.github.com/b42b5d78fbdc579a94...5ea4489280
[Coke] lizmat: looks like your module saves time over multiple calls in the same app, but app::uni is mostly inside a single invocation 16:09
lizmat in my benchmarks, it was faster :-)
but I realize it's subtly different was it just looks at *words* in the uniname string 16:10
so it would not return "FOUR LEAF CLOVER" when given "LOVE"
timotimo do we have some C LOVERs in here? 16:11
lizmat possibly, most people here program in C I'm told :-) 16:12
16:12 brrt joined 16:16 domidumont joined
[Coke] I'm sorry, I continued this convo in the wrong window. 16:16
brrt good * 16:20
MasterDuke nine++ on a bugfix roll recently 16:32
16:34 domidumont left
nwc10 good *, brrt 16:55
16:57 brrt left
lizmat so, should a BEGIN chunk in a block prevent it from inlining because of a capturelex? 17:11
17:16 domidumont joined
Geth MoarVM/fix_inlines_missing_synthetic_deopt_points: b22038ba9b | (Stefan Seifert)++ | 6 files
Fix inlines missing synthetic deopt points

Since commit 3345ec36466dbae315b00960d3afedf121b08451 we have synthetic deopt points on inserted guards. These deopt points take their index from an existing deopt point they are linked with. This is important as otherwise we might miss registers we need to restore when deoptimizing.
... (8 more lines)		 17:20
MoarVM: niner++ created pull request #1473:
Fix inlines missing synthetic deopt points		 17:21
nine That was a 10 hour workday... would have been fine with making it in half the time but alas, at least it's fixed
lizmat nine++
17:25 domidumont left 17:26 domidumont joined 17:50 domidumont left 18:08 zakharyas left
[Coke] nine++ indeed. 18:41
18:43 Geth left
sena_kun nine++ 19:18
19:39 patrickb joined
patrickb niner: github.com/croservices/cro-http/is...-822050963 <- Results when disabling different moar components. 19:57
20:19 patrickb left
jnthn I think the MVM_SPESH_PEA_DISABLE=1 in that one is the most telling 21:34
Probably inlining being disabled helps because it means something escapes to a callee and so PEA doesn't do a scalar replacement
timotimo we had the "stop spesh after a specific point" thing already, maybe we should expand that to different flags 22:08
may not be obvious for a couple of situations i guess

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!