github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo ah 00:00
00:00 lizmat joined 00:01 p6bannerbot sets mode: +v lizmat 00:02 nativecallable6 joined, bisectable6 joined, benchable6 joined 00:03 p6bannerbot sets mode: +v nativecallable6, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v benchable6 00:05 lizmat left 00:20 avar left 00:24 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 00:25 p6bannerbot sets mode: +v avar 01:04 yoleaux joined, p6bannerbot sets mode: +v yoleaux 01:10 thurin27 joined 01:11 p6bannerbot sets mode: +v thurin27 01:12 MarkAtwood7 joined 01:13 p6bannerbot sets mode: +v MarkAtwood7 01:14 MarkAtwood7 left 01:16 thurin27 left
timotimo imgur.com/CVEXRdT - shiny new "show allocations for all children" feature; it's like "inclusive allocations" except it gets the inclusive allocations for each child call and displays them in-line 01:28
(there's actually more; i forgot to include the routien itself in the "get inclusive allocations" so only children of each children were accounted for) 01:30
02:41 SporkWitch5 joined 02:42 p6bannerbot sets mode: +v SporkWitch5, SporkWitch5 left 04:22 tx2 joined 04:23 p6bannerbot sets mode: +v tx2 04:28 tx2 left 05:17 brrt joined 05:18 p6bannerbot sets mode: +v brrt 05:43 diakopter left 05:45 yoleaux left, yoleaux joined 05:46 p6bannerbot sets mode: +v yoleaux 06:18 robertle joined 06:19 p6bannerbot sets mode: +v robertle 06:26 Kaypie joined, Kaiepi left
brrt do we ever clean up the spesh graphs that we allocated during inlining? 06:27
06:27 p6bannerbot sets mode: +v Kaypie 06:34 AlexDaniel joined, onur14 joined, onur14 left 06:35 p6bannerbot sets mode: +v AlexDaniel 06:49 lizmat joined, p6bannerbot sets mode: +v lizmat 06:50 brrt left 07:01 holodoc6 joined 07:02 p6bannerbot sets mode: +v holodoc6 07:05 holodoc6 left 07:12 brrt joined 07:13 p6bannerbot sets mode: +v brrt 07:21 Kaypie left 07:33 Kaiepi joined 07:34 p6bannerbot sets mode: +v Kaiepi
brrt \o 07:37
I think we leak graphs allocated for inlines
which we normally don't notice, because we assign the inlines to the candidate, and we assign the candidate to the staticframe, and so we keep that alive 07:39
08:01 zakharyas joined, robertle left 08:02 p6bannerbot sets mode: +v zakharyas 08:08 brrt left 08:10 Kaiepi left 08:11 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 08:12 Kaiepi left 08:13 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 08:24 Kaypie joined, Kaiepi left 08:25 p6bannerbot sets mode: +v Kaypie 08:34 Kaypie left 08:35 Kaypie joined, p6bannerbot sets mode: +v Kaypie 08:44 Kaypie is now known as Kaiepi
jnthn brrt: We stash them away inside of the inline data strucutre in order to free them at the end of the specialization of the enclosing thing, as I remember it 09:21
09:40 brrt joined 09:41 p6bannerbot sets mode: +v brrt
brrt \o 09:41
jnthn hi brrt
brrt I think we're going to need reference counting on spesh graphs
jnthn ? 09:42
Why?
We never share them
brrt we take a reference to a spesh graph when inlining
jnthn Not really, we take ownership of it
We produce that graph precisely for the purpose of inlining
brrt hmmm
jnthn Because we then mutate it a load as part of the inline process 09:43
So it should just be freed when the graph it's incorporated into is being freed
brrt that would suggest we can clean it up during staticframe spesh gc free
jnthn We should actually be able to clean it up at the point spesh is done with it
brrt that leads to use-after-free issues pretty fast...
jnthn That is, as soon as it spits out the optimized bytecode and JITted output, it can go away 09:44
brrt i'd think so, yes
hmmm
jnthn If that isn't happening, that's a bug
brrt anyway, we don't currently clean them up, no
jnthn darn...for some reason my fix last night doesn't help the case it was meant to
09:45 robertle joined
brrt oh, i know why my fix doesn't work 09:45
I cleaned them up during spesh-graph-destroy
09:46 p6bannerbot sets mode: +v robertle
brrt however, in case of recursive inlining, the cleaned-up inline is going to point to inlines that are already freed 09:46
jnthn Ohh...I wonder how we JIT return... 09:48
aha
Having to update both the lego JIT and the expresssion JIT gets a tad tiresome :) 09:51
(And yes, I know, I should help write templates so we can expression JIT everything...)
brrt jnthn: agreed and noted... 09:52
maybe we should make it a goal to eliminate the lego jit 09:53
there's virtually nothing it actually does better
and.
jnthn *nod*
I figured that was the goal anyway, just that - like all things - it needs time, which is a limited resource.
brrt we can translate a bunch of the dynamic, untemplateable things, to expressions
lizmat is there a way that other people can help towards this goal ?
brrt well, a bunch of people have already been adding templates 09:54
lizmat so more power to them?
brrt definitely
there's a few things that we can't do in the expression JIT yet, notably SSE register selection
jnthn That's needed for floating point? 09:55
brrt yes
we barely use floating point, so it's not come up yet
there is a minor instruction encoding bug in dynasm for the upper 8 sse registers
jnthn Yeah, Hm, what's `dov`? 09:56
brrt do-void
jnthn oh...do void maybe? 09:57
:)
brrt we can have a better name there :-)
jnthn btw, what is it that blocks expr JIT of guards? (I know I've asked if they can be done, asking in case it's something I can do :))
brrt hmm... the only thing that i can think of, is that we might need to flush the locals table before compiling a guard 09:58
jnthn I see we have (^exit) as a template macro, which'd seem to be one part of it
brrt and i recall you asking if we could avoid that
jnthn ah...would ^exit not make that happen anyway? 09:59
brrt no, let me check what ^exit actually points to...
jnthn As in, force flush if we were leaving
Oh, but that's maybe too late
Yes, it can be too late :)
We need to flush before we call the C function that does the deopt
If flush means what I think it means :)
brrt it almost means that... there is two meanings here, and i'm not using them nicely separated 10:00
the first meaning is, while building expression trees, we maintain the nodes that generated a local; if we find a reference to that local, we add a reference to that node (if we do not find it, we generate a node that says 'load this local' and use that as a reference instead) 10:01
the second meaning is, before we call we must ensure that values that are (potentially) clobbered are saved and restored; that's done by the register allocator 10:02
In the context of guards, i'm referring to the first meaning; and the implication is that before we return to the interpreter, the stack frame must be as if it was interpreted 10:03
It might be better to handle that explicitly via some kind of 'sync' node
anyway, to make a long story short 10:05
(i can also make it longer ;-)) 10:06
there shouldn't be a problem with implementing guards
hmm. i'm confused now; the spesh graph candidate code *does* clean up inline spesh graphs 10:15
jnthn Grrr...turns out that just fixing the return type side of things isn't quite enough 10:21
Though it occurs to me that I'm also looking at a rather wasteful situation 10:25
We're producing type specializations of the NQP sub `sub identity($obj) { $obj }` 10:26
Which is utterly pointless because there's nothing to specialize in there
We should just produce one simple ("certain") optimized version of it and be done
brrt odd... 10:28
jnthn Well, we don't yet do anythhing to analyze if type specializations are even worth it 10:29
brrt anyway, the issue is, we're not freeing spesh graphs that have been allocated as part of try_unoptimized
jnthn works on that :)
brrt and only those are a problem
jnthn Hm, is that the new path?
For when there was no existing specialization? 10:30
brrt correct
but as far as I can tell, these are as normal?
jnthn hmm, wonder if a destroy of the spesh graph if we can't inline it is missing
lizmat jnthn: I guess you are aware that "identity" takes about 5% in my average profile
jnthn lizmat: That's how I know the profiler is introducing its own measurement noise 10:31
lizmat aha... ok
:-)
jnthn I suspect that with the expr jit we turn the content of identity into 1 or 2 machine code instructions
Even calling the profiling logging is more than that
Let alone its actually recording work
*actual 10:32
brrt gist.github.com/bdw/699471e0b284c8...01782ef3de
we could, if inlined, and the optimizer works, and the register allocator optimizations work, etc. 10:33
no, we actually do clean that up.. hmm 10:39
o.O but, recursively, as well.. 10:40
10:43 d0nn1e joined 10:44 p6bannerbot sets mode: +v d0nn1e
brrt i could use a hint with the log above because i don't really get it 10:44
10:49 d0nn1e left
Geth MoarVM: 286b56079d | (Jonathan Worthington)++ | 4 files
Log return type in return from JIT to unspesh'd
 10:52
MoarVM: 5ef56b7268 | (Jonathan Worthington)++ | 4 files
Add data on which ops are specializable

We'll use this data to decide when there's no point producing type specializations for a frame, and we should just go with making a single certain specialization for it instead.
jnthn Hm, it's the spesh graph structure itself that leaks, rather than the memory allocator within it... 10:53
brrt aye 10:55
well, also everything in it 10:56
11:04 zakharyas left 11:09 Exaeta joined, Exaeta left, travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Add data on which ops are specializable 11:09
travis-ci.org/MoarVM/MoarVM/builds/413998366 github.com/MoarVM/MoarVM/compare/5...f56b726889
11:09 travis-ci left
Geth MoarVM: 0c5f6e52e4 | (Jonathan Worthington)++ | 4 files
Don't do worthless type specializations

Note whether a static frame contains anything that would benefit from type specialization. If it contains no such instructions, then only do a certain specialization of it. This works well with the `identity` sub written in NQP and produced by various spesh plugins. With a bit more work in Rakudo it may be possible to get Mu.sink to be considered as an unspecializable thing too.		 11:16
lizmat jnthn: work in Rakudo where ?
jnthn Looking at the bytecode, seems 2 things (at least) 11:18
1) Don't bother spitting out a p6decontrv when we can see we're returning Nil (or something else that won't use it) 11:19
2) Twiddle the signature lowering so that a type constraint of Mu on an invocant won't spit out a hllize
Can't do that for non-invocant Mu things, but when it's the invocant, well, we'll get away with it I guess :) 11:20
Lunch time; will have a play with that afterwards 11:21
lizmat ok
meanwhile: I have a patch that will strip out the Stringy calls, making the core 36K smaller
jnthn OK, does it come out just as fast when interoplating non-Str? 11:22
lizmat faster
jnthn oh, nice :)
lizmat 1414 msecs vs 1713
jnthn bbiab
11:27 statisfiable6 joined, p6bannerbot sets mode: +v statisfiable6 11:34 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Don't do worthless type specializations 11:34
travis-ci.org/MoarVM/MoarVM/builds/414006475 github.com/MoarVM/MoarVM/compare/5...5f6e52e469
11:34 travis-ci left
dogbert17 brrt: did you see the asan output I posted on github.com/MoarVM/MoarVM/issues/862 ? 11:39
11:49 mcspud26 joined 11:50 p6bannerbot sets mode: +v mcspud26 11:51 rorx15 joined, AlexDaniel left, rorx15 left 11:55 mcspud26 left
jnthn Ah, turns out that there's also a decont in method sink and that has to be there, and that's desirable to specialize 12:08
So, we don't get it to fall under unspecializable. But still we can get it not to do a pointless p6decontrv :) 12:09
masak hm, Rakudo extops are going away? 12:12
jnthn Yes, slowly but surely 12:15
masak why? is the flexibility of extops not worth it? 12:18
or is this some sort of natural development like "moar is taking on more and more of the special needs rakudo has"? 12:19
lizmat masak: extops cannot be jitted
jnthn They made more sense when we were at the point where "write chunks of hot stuff in C" was good
masak ah, so this is a step in the lifting of things
jnthn Well, we can JIT the calls to them, but we can't look inside of them 12:20
So for example return type checking and deconting and so forth used to be a check we coulod not avoid
*could
And many Scalar allocations took place magically inside of C code that allocated them and set the descriptor and default value, which would be invisible to escape analysis 12:21
masak oh no
jnthn That bit was already changed :)
Note how if you have an interpreter and don't have any significant optimization infrastructure, it makes sense to do things with hunks of C in extops 12:22
But now we have compilation to machine code and an increasingly sophisticated optimizer
masak right
12:23 robertle left
masak will the extops go away completely, then? 12:23
will it just be "0 extops", or will it be "the extops mechanism can be removed now"? 12:24
lizmat masak: I think that's the plan 12:25
jnthn Since Rakudo is the only customer, I think we could even remove it 12:26
masak yay
jnthn One nice side-effect of this is that we then can do static builds of MoarVM
And they can run Rakudo
Which will be very helpful for those wanting to bundle stuff into a single executable for distribution purposes 12:27
masak yes, it was through that issue that I found that extops are going the way of the dodo 12:30
12:38 zakharyas joined 12:39 p6bannerbot sets mode: +v zakharyas 12:45 Kaiepi left, Kaypie joined 12:46 p6bannerbot sets mode: +v Kaypie 12:53 diakopter joined, p6bannerbot sets mode: +v diakopter 13:14 brrt left, brrt joined 13:15 p6bannerbot sets mode: +v brrt 13:20 dodobrain16 joined 13:21 p6bannerbot sets mode: +v dodobrain16, dodobrain16 left 13:35 brrt left 13:50 Kaypie left 13:52 Kaiepi joined 13:53 p6bannerbot sets mode: +v Kaiepi 13:58 davidebeatrici15 joined 13:59 p6bannerbot sets mode: +v davidebeatrici15 14:02 davidebeatrici15 left, JustTheDoctor joined, p6bannerbot sets mode: +v JustTheDoctor 14:03 AlexDaniel joined, JustTheDoctor left, p6bannerbot sets mode: +v AlexDaniel 14:04 AlexDaniel left, AlexDaniel joined, card.freenode.net sets mode: +v AlexDaniel, p6bannerbot sets mode: +v AlexDaniel 14:06 timotimo left, AlexDaniel left, AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 14:16 nhandler23 joined, p6bannerbot sets mode: +v nhandler23 14:17 nhandler23 left 14:35 Kaiepi left, Kaiepi joined 14:36 p6bannerbot sets mode: +v Kaiepi 14:53 roger_rabbit17 joined 14:54 p6bannerbot sets mode: +v roger_rabbit17 14:55 roger_rabbit17 left 15:37 timo joined, p6bannerbot sets mode: +v timo, timo is now known as timotimo 15:41 lizmat left
Geth MoarVM: 210a4026f5 | (Jonathan Worthington)++ | 4 files
Make inline logging available through an env var

Having to compile it in my tweaking a #define every time gets quite tiresome. This also makes it accessible to those doing development on Rakudo, without them having to re-compile MoarVM.		 15:42
timotimo ^- i like that 15:45
15:54 brand021 joined 15:55 p6bannerbot sets mode: +v brand021 15:56 brand021 left 15:58 zakharyas left 16:02 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Make inline logging available through an env var 16:02
travis-ci.org/MoarVM/MoarVM/builds/414122535 github.com/MoarVM/MoarVM/compare/0...0a4026f53c
16:02 travis-ci left 16:07 Zoffix joined, p6bannerbot sets mode: +v Zoffix
timotimo imgur.com/hNKA3lz - now you can also get the allocations for an "entire routine", rather than just in the call graph "per call" 16:20
even though actually using it has quite a few rough edges, i'll probably push it up to github and release it to the ecosystem Very Soon, plus a blog post 16:24
Zoffix New blog post: "The 100 Day Plan: The Update on Perl 6.d Preparations": rakudo.party/post/The-100-Day-Plan...6-d-Update 16:48
16:54 AlexDaniel left 16:55 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 16:58 thomas23 joined
jnthn Darn. I figured we could do a dead instruction pass before deopt use analysis, which would act mostly as a PHI prune 16:58
16:58 p6bannerbot sets mode: +v thomas23
jnthn And it makes a measurable difference in some benchmarks. Oddly, though, breaks the Rakudo build. It's odd, given it should be entirely safe.. 16:58
16:58 Zoffix left 16:59 thomas23 left
timotimo hah, yeah 17:03
i experienced something similar to that
when i tried to trim PHI nodes down to only have one mention of each register version
17:03 pwillard10 joined
timotimo maybe we've got some code that removes phi operands from a "pred" block when we remove something or other 17:04
and that lacks an idea of usage/reference count/whatever
17:04 p6bannerbot sets mode: +v pwillard10
jnthn Dunno 17:05
17:10 pwillard10 left 17:13 nesthib joined, p6bannerbot sets mode: +v nesthib 17:14 nesthib left 17:16 brrt joined 17:17 p6bannerbot sets mode: +v brrt 17:20 brrt left 17:23 brrt joined, p6bannerbot sets mode: +v brrt
jnthn hah, obvious problem in hindsight 17:32
timotimo cool, what was it?
jnthn It was doing it when re-using a specialization
And so threw out stuff that deopt analysis had carefully retained :)
timotimo huh, so it did it twice to the same phi?
jnthn Well, re-use means we make a graph from already specialized code
But we don't have enough information in the code to know that we can't just go throwing things away 17:33
(Because they will have no visible use, but will have been retained last time around for deopt reasons)
timotimo ooh
diakopter jnthn: it occurs to me that the spesh knowledge engine could be used to make a "real" type checker 17:35
(like, Agda/Coq/Idris-grade) 17:36
...if there was a Calculus of [inductive] Constructions HLL, that is 17:37
timotimo difficult to do, IMO, since we do multi-dispatch by caching what the actual dispatch code tends to do at run time 17:39
and then just ignore the other methods and such
jnthn Loads of stuff in spesh is done speculatively and so based on statistics
So it's be a probabalistic type checker... :) 17:40
diakopter but that's the essence of type-checking, proving that checks that could theoretically just be runtime checks are actually invariants that can be optimized away
timotimo we still keep a whole lot of these checks around, though
17:40 dimi34ka joined 17:41 p6bannerbot sets mode: +v dimi34ka
diakopter if one doesn't care about proving consistency of a program specification offline (doesn't mind encountering misdesigns/bugs at runtime), such a system would be just fine 17:42
17:44 dimi34ka left 17:49 brrt left
timotimo there's still lots of places we do invocations, where potentially all our knowledge is just gone 17:49
17:57 chachasmooth3 joined 17:58 p6bannerbot sets mode: +v chachasmooth3 18:03 chachasmooth3 left
Geth MoarVM: bfbbb0f75c | (Jonathan Worthington)++ | 9 files
Do dead instruction elim pass after usage setup

But before we do the deopt analysis. While it's of course possible that there was dead code in the input program, the main purpose of this is to trim away dead PHI nodes, recursively, so that they will not make extra work for the deopt analyzer nor cause things to be kept alive bogusly just because a PHI was used across a deopt point. ... (5 more lines)		 18:11
jnthn oops, it's very much dinner time 18:15
yoleaux 17:48Z <Zoffix> jnthn: FYI: R#2195 github.com/rakudo/rakudo/issues/2195
synopsebot R#2195 [open]: github.com/rakudo/rakudo/issues/2195 [āš  blocker āš ] False positive throwage of "flattening of other hash reprs NYI"
jnthn bbl
18:34 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build errored. Jonathan Worthington 'Do dead instruction elim pass after usage setup 18:34
travis-ci.org/MoarVM/MoarVM/builds/414185404 github.com/MoarVM/MoarVM/compare/2...bbb0f75c7f
18:34 travis-ci left 18:42 lizmat joined 18:43 p6bannerbot sets mode: +v lizmat 19:00 Guest42469 joined 19:01 p6bannerbot sets mode: +v Guest42469 19:02 Guest42469 left 19:05 varesa12 joined, p6bannerbot sets mode: +v varesa12 19:06 varesa12 left 19:27 cwre joined 19:28 p6bannerbot sets mode: +v cwre, cwre left 19:31 Zombie23 joined, Zombie23 left
dogbert17 jnthn: wrt to github.com/MoarVM/MoarVM/issues/937 the same problem shows up with every program, even ./perl6 -e '' 20:06
jnthn Looks harmless, if noisy 20:09
dogbert17 ok, no worries then but nwc10 will scream bloody murder tomorrow :) 20:10
jnthn Maybe, but he uses ASAN, and I'm not sure if that detects this particular kind of problem ;) 20:11
hm, does it happen for NQP code ever? 20:12
Geth MoarVM: efbc6c6389 | (Jonathan Worthington)++ | src/core/ext.c
Fix an uninitialized memory access

It was relatively harmless, and only happened when validating frames that used extops; this gives it an accurate value.		 20:16
dogbert17 ooh, now that was fast, jnthn++ 20:17
can I ask another favor, what happens if you run ./perl6 t/spec/S06-signature/introspection.rakudo.moar 20:19
I get a strange error just near the end - Cannot invoke null object
jnthn hm, I get that too 20:20
Strange, didn't on my work machine
diakopter microcode-patched Intel CPU vs non- ? 20:21
jnthn Probably just timing related
diakopter :D
dogbert17 Ryzen here :)
seem to be the last commit you did before dinner, i.e. bfbbb0f75c7 20:31
timotimo if moar could analyze lexicals better, it could remove the "assign 0 to the lexical" before the argument gets assigned 20:35
this is talking about the Int candidate for ASSIGN-POS
timotimo looks at the int candidate instead 20:36
20:37 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Fix an uninitialized memory access 20:37
travis-ci.org/MoarVM/MoarVM/builds/414235385 github.com/MoarVM/MoarVM/compare/b...bc6c6389d7
20:37 travis-ci left
timotimo 592 bytes big, 54 from the scalar-assign-no-whence-no-typecheck farme it's inlined 20:38
20:38 lizmat_ joined 20:39 p6bannerbot sets mode: +v lizmat_ 20:40 lizmat left
timotimo maybe spesh should try to use getattr_o instead of getspeshslot + getattrs_o 20:41
maybe "if it can find the string in the string heap and it's already deserialized"
but that could be an expensive lookup, perhaps?
the getattrs_o could be made better if we could discover facts from the guards 20:45
but for that they would have to up the version of the register, or some other way to signal that what they are guarding against is only known to be true after the guard
jnthn It should be able to turn it into that 20:46
timotimo oh? well, it doesn't in this case :)
it has 0 facts about the register it's using for the getattrs_o, i.e. operand number 2 20:47
jnthn Yeah, I spotted that. Didn't figure out why yet.
timotimo oh, did you also see it's "KnTyp" on one of the target registers of getspeshslot? 20:48
like, only known type, not known value?
that's also odd
dogbert17 another observation, t/spec/S17-procasync/stress.t suddenly behaves very strangely
timotimo if it's gone through facts_discover, it must have known type *and* known value, unless the "obj" passed in is null 20:49
jnthn What the heck? when I set spesh_limit etc. I get a spesh log full of junk? 20:57
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
And nothing useful 20:58
timotimo that sounds like multithraeding
put a %d into the filename
that can help
not multithreading
multiple processes
like when precompilation happens
jnthn huh, indeed 21:01
timotimo ^@ is null 21:02
jnthn Perhpaps the test shells out
I do get 3 files
ah, and only one thing has something in it 21:03
timotimo only one reaches limit
jnthn Right 21:04
(That part is good, I odn't have to figure out which to look at :))
timotimo holding cat with othen hand
except for eliminating some "set"s and the getattrs_o thing that could have two less getspeshslot in front i don't see big opportunities for winning in bytecode size from spesh alone 21:10
hm, but each set is 3 x 16 bytes, right? so 48 21:11
i suppose that adds up rather quickly
if we don't mind special-casing it everywhere in the whole codebase, we could have a set instruction that only works on the first 256 registers, but encodes both arguments in 16 bytes instead of 32 for both 21:12
diakopter I think we considered that a while back 21:16
21:16 timotimo left
diakopter where'd e go 21:17
jnthn OK, the introspection.t failure is deopt related, it seems 21:19
21:34 timo2timo joined, p6bannerbot sets mode: +v timo2timo
timo2timo the shell host is a bit rebooty today it seems like 21:34
earlier today it was an update, no clue what it is this time
i mean we can also just deduct some bytes for every "set" instruction in the code 21:35
jnthn oh, very darn clever 21:43
So we have a bunch of deopt instructions
Well, deopt points 21:44
The deopt usage checker correctly considers them as deopt usages of the register that goes missing
However, after optimization, none of them are left on guards or other potentially deopt instructions 21:45
So it deletes them. All very good.
Except that one of the invokes was a completely non-speculative inline
And the inline deopts
But we don't factor that in anywhere
This was wrong before now, but all the surplus PHIs saved us
timo2timo hah 21:46
jnthn I think that may be relatively easy to fix
21:46 lizmat_ is now known as lizmat
jnthn I'd already been wanting the "does this inline have any deopt points" info anyway 21:49
21:59 sam21 joined 22:00 sam21 left, Kaiepi left 22:02 siniStar joined 22:03 siniStar left 22:08 timo2timo left 22:09 lizmat left 22:12 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 22:14 Turska-29 joined, lizmat joined, p6bannerbot sets mode: +v Turska-29 22:15 Turska-29 left, p6bannerbot sets mode: +v lizmat, __idiot__ joined, __idiot__ left 22:23 mark-otaris joined 22:24 mark-otaris is now known as Guest76862, p6bannerbot sets mode: +v Guest76862, Guest76862 left 22:31 timo2timo joined, MJ940 joined 22:32 p6bannerbot sets mode: +v timo2timo, p6bannerbot sets mode: +v MJ940, MJ940 left
jnthn Yay, seems I have a fix. 22:35
timo2timo \o/ 22:37
Geth MoarVM: 4fc267b607 | (Jonathan Worthington)++ | 6 files
Account for inlines that may cause deopts

It was possible for us to wrongly discard instructions based on them not being needed for deopt when:
  * There code being specialized did not need to use any of the deopt
   points between the definition and use of the SSA value
  * An inline inserted between the two could cause deopt
Fix by using a deopt point at the point of the call as a "proxy" for those deopts inside of the inline, when an inline has instructions that may cause deopt.		 22:44
22:53 timo joined, p6bannerbot sets mode: +v timo, timo is now known as timotimo
dogbert17 there's a tiny problem left but that should perhaps be left for later 22:55
running ./perl6-valgrind-m t/spec/S06-signature/introspection.rakudo.moar will expose it 22:56
23:03 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Jonathan Worthington 'Account for inlines that may cause deopts 23:03
travis-ci.org/MoarVM/MoarVM/builds/414291605 github.com/MoarVM/MoarVM/compare/e...c267b607b9
23:03 travis-ci left
timotimo most important user-facing feature: invoking the profiler UI when a profile was already loaded before will now immediately forward you to the profiler ui 23:04
now it'll have to load files specified on the commandline, too
23:27 greppable6 joined 23:28 p6bannerbot sets mode: +v greppable6 23:35 obserd joined 23:36 p6bannerbot sets mode: +v obserd 23:37 obserd left

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!