01:07
jnap joined
01:25
lue joined
01:36
FROGGS_ joined
01:49
cognome joined
03:14
ventica joined
04:12
lue joined
04:30
retupmoc1 joined,
hatsefla1s joined
04:35
zakharyas joined
04:36
betterworld joined
04:42
ingy joined,
egrep joined
|
|||
nwc10 | jnthn: aafb3aaba4a81fce81ce976af52825158bb33a7a PASS | 04:44 | |
04:48
ingy joined
04:53
ventica joined
04:55
ventica2 joined
05:16
egrep left
05:21
brrt joined
|
|||
brrt | jnthn++ for his My First Jit Patch | 05:42 | |
07:04
_sri joined
07:09
Ven joined
|
|||
sergot | hi o/ | 07:20 | |
brrt | hi sergot | 07:21 | |
07:37
woolfy left
|
|||
brrt | label management is complex in general, it seems | 07:52 | |
but i think i can generalise it and it'll be BETTER | 07:57 | ||
timotimo | brrt: sounds good :) | 08:01 | |
brrt | i should elaborate by the way | 08:02 | |
(by the way, i can't stress enough how much jnthn++ saved me yesterday) | |||
basically, we now assign labels to basic blocks, and we assign magic special labels to osr entry opts | |||
but from the point of view of the assembler, all these labels are of the same type (i.e., dynamic labels) | 08:03 | ||
i can have pretty much as many of these as i like | |||
my current setup has the osr labels appended to the 'regular' bb labels | |||
because while there is a mechanism to ensure that the same basic block will receive the same label at all times, no such mechanism exists for individual ops - and that is what is needed for OSR labels (and frame handler labels) to work in general | 08:04 | ||
on the other hand, the only thing that mechanism uses is pointer identity for the basic blocks, so adding ops to that changes nothing | 08:05 | ||
in fact, with the deopt_all_idx field added to the MVMJitLabel structure, these structures now have all we might need for any of OSR/handler/inline | 08:08 | ||
we can also remove the special osr label code | 08:13 | ||
because it will not be special anymore | |||
timotimo | :) | 08:14 | |
08:39
FROGGS[mobile] joined
08:40
klaas-janstol joined
|
|||
jnthn | morning, #moarvm o/ | 08:57 | |
timotimo | heyo :) | ||
nwc10 | jnthn++ # saviour of the universe | ||
timotimo | i still kinda wish our REPL wasn't based on such a ... hack | ||
08:58
brrt joined
|
|||
brrt | moarning jnthn :-) | 08:59 | |
nwc10 | www.youtube.com/watch?v=LfmrHTdXgK4 | 09:00 | |
(not a rickroll. However, we don't have a bot to verify that. Which makes me wonder about having a bot that usually tells the truth, but sometimes hides a rickroll) | |||
jnthn | :P | 09:01 | |
nwc10 | they all look so young | ||
timotimo | that is still an excellent song | ||
what do you mean, "flash jnthn approaching?" | 09:02 | ||
nwc10 | I think of individual Queen songs, Killer Queen is still my favourite | 09:03 | |
09:22
brrt joined
10:23
FROGGS[mobile] joined
|
|||
nwc10 | before I forget, setting takes about 15% less time with spesh than without. | 10:40 | |
jnthn | Yeah, that sounds similar to the numbers I've observed | 10:42 | |
Makes quite a difference. | |||
timotimo | yes, spesh is good. | 10:43 | |
jnthn | Still plenty of room to make it better, though :) | 10:44 | |
timotimo | of course | ||
.o( set elimination ) | |||
jnthn | .oO( I just tossed set, and it felt so good... ) |
10:45 | |
timotimo | just now i remembered how long i used to wait for the setting compilation to test if my newest Optimizer.nqp change worked properly | 10:52 | |
brrt | :-) yay for spesh | 10:59 | |
brrt bbi3h | |||
timotimo | between then and now there were a whole lot of other changes, though. like the introduction of moarvm | ||
11:12
FROGGS[mobile] joined
11:48
FROGGS[mobile] joined
12:26
klaas-janstol joined
|
|||
timotimo | jnthn: gist.github.com/timo/148021dfebabafccfa6a - got an idea why this happens? | 12:30 | |
(someone else pointed this out recently, but i've only checked it out now) | 12:31 | ||
(i don't think it'll make a huge performance difference, but ... why are we doing this %) ) | 12:33 | ||
jnthn | Is that a full strace? | 12:37 | |
It looks like it's loading a lib over and over again rather than hitting a cached previous loading... At least, I thought we cached the pervious loading... | 12:38 | ||
*previous | |||
timotimo | it's only a small part of the whole strace | 12:40 | |
jnthn | was gonna say | ||
timotimo | is this MVM_dll_load? | 12:41 | |
can you just MVM_HASH_GET with an MVMString like that? | |||
12:43
jnap joined
|
|||
timotimo | actually | 12:44 | |
it could very well be MVM_file_in_libpath | |||
i bet it is. | 12:46 | ||
this one doesn't do any caching. | |||
so either we add a cache to MVM_file_in_libpath or we make the cache of dll_load depend on the not-full path | 12:47 | ||
which would probably be a bad idea. | 12:48 | ||
maybe we should bind each dll into the hash twice. once with the full path, once with just the filename | |||
interesting. MVM_dll_free would require the user to pass the full path to the dll to free it | 12:52 | ||
jnthn | Can libpath be changed today after startup? | ||
If it's immutable then caching on short name is safe. | |||
timotimo | it seems like we only ever set the libpath from commandline arguments | 12:53 | |
jnthn | Right | ||
So it's safe to cache on short name. | |||
timotimo | so should it only cache on short name or on both? | 12:54 | |
oh | |||
d'oh | |||
it *is* caching on short name | |||
but it is trying to find the file in the libpath before even checking the cache | |||
timotimo fixes | |||
much better. | 12:56 | ||
dalek | arVM: 831e654 | (Timo Paulssen)++ | src/core/dll.c: check dll cache before searching through libpath |
12:57 | |
jnthn | Any measurable startup time improvement? | ||
timotimo | don't think so | 12:58 | |
file_in_libpath was already rather tight | |||
and stat likely has its own cache built in | |||
internet says it's cached | 12:59 | ||
jnthn | aye | 13:00 | |
moritz | ... on sane platforms :-) | ||
jnthn | Well, makes strace of our startup look better... | ||
timotimo | ;) | 13:01 | |
it'll improve the startup time if strace is attached | |||
I/O to stdout/stderr is expensive, you know? :D | |||
also, loading a library adds a permanent gc root, but freeing it does not ... | |||
moritz | well, syscalls also have a certain overhead | ||
jnthn | timotimo: I also notice mmap(NULL, 233472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd4b9bf2000 | 13:04 | |
Is that a bytecode loading? | 13:05 | ||
timotimo | dunno, it happens over and over and over in perl6-m -e 'say 1' | ||
about 240 times | 13:06 | ||
jnthn | Always with read/write? | ||
We do MVM_platform_map_file(fd, &handle, (size_t)size, 0) | 13:07 | ||
the 0 there is meant to indicate "not writable" | |||
timotimo | 27 are PROT_READ only | ||
10 are PROT_EXEC | 13:08 | ||
2 of those with NULL as first argument | |||
the others with pointers | |||
jnthn | Ah, ok | ||
timotimo | (it's a jit-moarvm) | ||
jnthn | 27 is about right for libraries loaded I uess | ||
Yes, and rest will be JIT allocating executable memory | |||
OK, seems fine | |||
timotimo | except MVM_JIT_DISABLE=1 doesn't change that | 13:09 | |
i'd like to resume work on the IPerl6 kernel thingie again ... that'll require me to build a new HLL::Compiler i think | 13:29 | ||
with a different interactive() method | |||
github.com/timo/iperl6kernel/blob/...el.nqp#L22 - this won't fly at all ... given the pir:: ops in there %) | 13:30 | ||
tadzik | :D | 13:31 | |
jnthn | timotimo: One can subclass... :) | 13:32 | |
timotimo | could i subclass it in perl6 code nowadays? | ||
jnthn | um | ||
Ask FROGGS ;) | |||
timotimo | also, yeah, i meant subclass not "build from scratch" ;) | ||
m: use NQP::HLL; | 13:40 | ||
camelia | rakudo-moar 35d714: OUTPUT«===SORRY!===Could not find NQP::HLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6» | ||
timotimo | m: use NQPHLL; | ||
camelia | rakudo-moar 35d714: OUTPUT«===SORRY!===Could not find NQPHLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6» | ||
timotimo | m: use HLL; | ||
camelia | rakudo-moar 35d714: OUTPUT«===SORRY!===Could not find HLL in any of: /home/p6eval/rakudo-inst-2/languages/perl6/lib, /home/p6eval/rakudo-inst-2/languages/perl6» | ||
timotimo | m: use HLL:from<NQP>; | ||
camelia | rakudo-moar 35d714: OUTPUT«===SORRY!===While looking for 'HLL.moarvm': no such file or directory» | ||
timotimo | m: use NQPHLL:from<NQP>; | ||
camelia | ( no output ) | ||
timotimo | m: use NQPHLL:from<NQP>; class Foobar is HLL::Compiler; | 13:41 | |
camelia | ( no output ) | ||
timotimo | hmm | ||
but i want Perl6::Compiler | |||
timotimo hunts | |||
oh | |||
jnthn | m: use Perl6::Compiler:from<NQP>; say 'ok' | 13:42 | |
camelia | rakudo-moar 35d714: OUTPUT«ok» | ||
jnthn | m: use Perl6::Compiler:from<NQP>; class FooBar is Perl6::Compiler; say 'ok' | ||
camelia | rakudo-moar 35d714: OUTPUT«ok» | ||
timotimo | m: use Perl6::Compiler:from<NQP>; class MyCompiler is Perl6::Compiler; MyCompiler.new().usage() | 13:43 | |
camelia | rakudo-moar 35d714: OUTPUT« [switches] [--] [programfile] [arguments]  With no arguments, enters a REPL. With a "[programfile]" or the "-e" option, compiles the given program and by default also executes the compiled code.  -c …» | ||
timotimo | this is good stuff. | ||
jnthn | m: use Perl6::Compiler:from<NQP>; class MyCompiler is Perl6::Compiler; MyCompiler.new().eval("say 'i accidentally the whole cake'") | 13:44 | |
camelia | rakudo-moar 35d714: OUTPUT«===SORRY!===Cannot find method 'parse'» | ||
timotimo | being able to toss the nqp portion of IPerl6Kernel would be a good thing. | ||
jnthn | Aww | ||
Guess it needs a bit more setup than that. | |||
timotimo | i may have to do the same thing as ... | 13:45 | |
github.com/rakudo/rakudo/blob/nom/...er.nqp#L14 | 13:46 | ||
anyway, AFK for a bit. | |||
(brrt is bound to return soon :D ) | |||
jnthn | .oO( be right brrt ) |
||
14:36
zakharyas joined
14:51
brrt joined
|
|||
brrt | \o | 14:56 | |
jnthn | o/ | ||
brrt | how 's it :-) | 14:58 | |
i would like to bounce the following idea off against you | |||
a): during jit-graph building, i'll be building a single array of labels, for basic blocks, osr points, inline start / ends, handlers, etc | 14:59 | ||
jnthn | inline start/ends are always aligned with basic block boundaries, fwiw. | 15:00 | |
brrt | b): also during jit-graph buidling, i'll be building an array containing the indices of the basic block labels, another array for the osr points, another array for inline starts / ends, another for the deopt indices | ||
jnthn | You do need to be very careful over the fact that some annotations are inclusive bounds and others are exclusive. | 15:01 | |
brrt | hmmm | ||
which are inclusive? | |||
jnthn | But yes, it's sane overall | ||
brrt | good point of course | ||
jnthn | Well, start of exception handler for example | ||
brrt | uhuh | ||
jnthn | It means "this instruction is where it starts" | ||
Same for inline | 15:02 | ||
But end of inline, for example, is on the last inlined instruction | |||
But clearly the body of that instruction (the code we generate for it) falls within the region. | |||
brrt nods | 15:03 | ||
jnthn | Thus why my patch yesterday for deopt all makes a note saying "it's the next thingy that gives the boundary" | ||
Anyway, provided you handle that, what you suggest seems sane. | |||
brrt | ok, good :-) i was afraid i was overgeneralising or something like that | 15:05 | |
but in fact some things seem to be simpler with it | |||
jnthn | Yeah, my patches in the JIT code yesterday were not aimed at being general, just getting me enough so I could write the patch in deopt.c and get that working. | 15:09 | |
brrt | well, it showed the way quite effectively :-) | 15:11 | |
and, i've an awesome topic to blog about | 15:12 | ||
15:27
klaas-janstol joined
|
|||
jnthn decides he's done enough $dayjob for today :) | 15:31 | ||
moritz too | 15:37 | ||
jnthn | Hm, I'm hungry too. | ||
Guess I should eat before hacking... :) | |||
brrt | that is rarely a bad idea | 15:40 | |
although too large meals make hacking difficult as well | |||
15:40
klaas-janstol joined
|
|||
jnthn tends to not eat too many carbs when making food for himself, which helps :) | 15:43 | ||
brrt | i suppose so | 15:44 | |
:-) | |||
eating & | 15:45 | ||
[Coke] | MVM_JIT_DONT_JIT_ME_BRO | 16:13 | |
jnthn | heh, I can call the option that if you like :P | 17:32 | |
TimToady | But if we use that option, we'll never make the top-50 jit list! | 17:35 | |
hmm, I guess it's supposed to be top 40... | 17:38 | ||
dalek | arVM: 2dd65b9 | jnthn++ | src/core/ext.h: Some extra JIT-related flags for extops. Put in master so we can add them to Rakudo's extops without having to make a branch there. |
17:41 | |
17:47
colomon joined
|
|||
TimToady | The crowd started to chant: "Merge! Merge! Merge! Merge!" | 17:50 | |
timotimo | Grand Theft Garbage Collector: 25 missions to steal from kindergartens, 1 to steal from an old folk's home | 17:53 | |
jnthn | :P | 17:54 | |
I think after brrt++'s current work on extent lists for handlers etc. we'll be at a good place to merge. | |||
dalek | arVM/jit-extops: 831e654 | (Timo Paulssen)++ | src/core/dll.c: check dll cache before searching through libpath |
18:08 | |
arVM/jit-extops: 2dd65b9 | jnthn++ | src/core/ext.h: Some extra JIT-related flags for extops. Put in master so we can add them to Rakudo's extops without having to make a branch there. |
|||
arVM/jit-extops: 9fb0d5d | jnthn++ | src/core/ (2 files): Merge branch 'master' into jit-extops |
|||
nwc10 | timotimo: reminds me of "Grand Theft Tricycle", which was a game a friends son seemed to be playing. | 18:10 | |
[if he saw anything with wheels, he tried to take it to play with it] | 18:11 | ||
timotimo | %) | 18:12 | |
jnthn | grmbl...segvs weren't much to do with jitting extops we coudln't | ||
timotimo | that sentence was challenging | ||
jnthn | So's this debugging :P | 18:13 | |
18:14
klaas-janstol joined
18:27
klaas-janstol joined
18:28
cognome joined
|
|||
jnthn | oh, duh duh duh | 18:44 | |
Seems it's a case of us now JITting frames we couldn't before and hitting another bug | |||
And I can get I know what. | |||
append_ins: <gethow> | |||
Need to update that for lazy deserialization :) | 18:45 | ||
timotimo | aaaah :) | 18:47 | |
probably | |||
jnthn | Ooh, and I think I can fix it without having to pretend to know how to write x86 assembly... :P | 18:48 | |
timotimo | sweet! | 18:52 | |
nwc10 | cd - | 18:53 | |
jnthn: origin/jit-extops has SEGVs in the spectest, but I guess you know that already | 18:54 | ||
seems to be just SEGVs, not ASAN barfage | |||
jnthn | nwc10: Yes, that's exactly what I was talking about above | ||
yeah, null pointer derefs | |||
nwc10 | OK. ASAN build gets as far as the spectest, so all the earlier stuff is clean | ||
jnthn | OK, good, then you're seeing what I am | ||
e | 18:55 | ||
19:09
brrt joined
|
|||
brrt | \o | 19:12 | |
gethow is called before, i'm pretty sure? but perhaps not in a lazily-loaded-context | |||
also | |||
this thing is getting out of my hands :-) | |||
(and i like that, by the way) | 19:13 | ||
dalek | arVM/jit-extops: 045252c | jnthn++ | src/ (4 files): Account for no_jit and invokish extop flags in JIT |
||
arVM/jit-extops: bccf73c | jnthn++ | src/ (3 files): Bring gethow JIT compilation in line with interp. Now it needs a function call, as we may lazily deserialize the meta-object. |
|||
timotimo | heyo brrt | 19:14 | |
jnthn | brrt: Yeah, none of the times we needed to do the lazy deserialize musta occurred in JITted code before | ||
brrt: Then the extops unblocked something that did a p6bool and a gethow | |||
timotimo | horton heard a how? | 19:15 | |
brrt | p6bool? | 19:16 | |
oh, p6bool is an extop? | |||
jnthn | aye | 19:17 | |
brrt | do we often pass STABLE's of objects? | 19:18 | |
jnthn | No | ||
brrt | because i can make a jit call arg mode for that :-) | ||
nwc10 | NQP tests pass. Now Rakudo | ||
brrt | ok | ||
[Coke] reads "heyo brrt" in the voice of ernie from sesame street. | 19:20 | ||
nwc10 | jnthn: all pass apart from t/spec/S26-documentation/10-doc-cli.rakudo.moar t/spec/S32-io/IO-Socket-Async.rakudo.moar t/spec/S32-str/encode.rakudo.moar | 19:32 | |
t/spec/S32-io/IO-Socket-Async.rakudo.moar is strange. It's planning 6 tests but only running 5 | 19:33 | ||
t/spec/S26-documentation/10-doc-cli.rakudo.moar is passing at the commandline | |||
anyway, win | 19:34 | ||
apart from the usual sin | |||
timotimo | sweet | 19:44 | |
jnthn | OK, I'll merge it into moar-jit | 20:01 | |
dalek | MoarVM/moar-jit: 16bde9a | jnthn++ | src/jit/graph.c: | 20:02 | |
MoarVM/moar-jit: An initial sketch of JITting extops calls. | |||
MoarVM/moar-jit: | |||
MoarVM/moar-jit: Doesn't yet fully work, most probably because it JITs some that are | |||
MoarVM/moar-jit: invokey without handling that, or that mess with interpreter state | |||
jnthn | lolextermianted | 20:03 | |
20:03
dalek joined
|
|||
brrt | poor dalek | 20:05 | |
(:-o it seems jnthn is racing ahead of me in terms of JIT commits this week) | |||
jnthn: the deopt all idx is always on the invoke op, right? wouldn't make much sense on arg_* ops | 20:09 | ||
jnthn | Correct | ||
brrt | ok, very well | 20:17 | |
wait, something just broke in my idea | 20:24 | ||
... darn it | |||
jnthn | oh? :( | 20:25 | |
brrt | i can't just combine the deopt idx into the label, because: what happens if the label assigned to the deopt_all_idx is the same as the label assigned to the inline frame end | 20:26 | |
jnthn | A label may be involved in multiple extend lists, yes | 20:27 | |
For example, multiple handlers can be on one label too | 20:28 | ||
er, or start on one instruction | |||
brrt | so putting the idx on the label isn't going to work | ||
jnthn | Oh, I'd somehow got the impression you were going to take the deopt idx out of the label and instead keep some data structures on the jgb | ||
brrt | that was still true | 20:29 | |
except that those data structures would be simple arrays | |||
now they won't be :-) | |||
jnthn | You know how many inlines there are, though, and how many handlers | ||
20:30
jnap joined
|
|||
jnthn | So you could just pre-allocate those | 20:30 | |
And fill them in with label name by handler index found in the annotation. | |||
Or inline index for inlines. | |||
Then after the code is generated, resolve those labels as you build the real extent lists. | 20:31 | ||
brrt nods | |||
that's... no problem. that's just the correct solution | |||
:-) | |||
hmm.. i do figure i can make a jit deopt point object | 20:56 | ||
jnthn | .oO( But what will it object to? ) |
21:05 | |
brrt considers a bad deconstructivism joke, but can't figure one out | 21:08 | ||
cognome | Stage parse : moar(96372,0x7fff70ccc310) malloc: *** error for object 0x7fd11014c1f0: pointer being freed was not allocated | ||
on a fresh rakudo with moarvm | 21:09 | ||
on macos | |||
jnthn | :/ | 21:11 | |
Weird; we've been getting clean ASAN reports of late, I thought... | |||
cognome | ASAN? | 21:12 | |
jnthn | Address sanatizer | ||
A tool for detecting errors like this | |||
lee_ | no problems building on OS X here | 21:13 | |
brrt | no backtrace then, likely? | 21:14 | |
if you have os x you should checkout the moar-jit branch, it has support for setting up ASAN using a configure.pl flag | |||
which - i think - hasn't been backported to main yet | |||
(the configure.pl flag is incidently --asan :-)) | 21:15 | ||
it will give you a backtrace, but also a much slower build | |||
cognome | ok, I try that | ||
brrt | probably best not to enable jit, since main doesn't have that either | ||
cognome | perl Configure.pl --asan --gen-nqp --gen-moar --backends=moar ? | ||
brrt | hmm.. no that's from rakudo | 21:16 | |
you'll need to configure moar with the --asan flag, not rakudo | |||
cognome | and how do you do that? | ||
brrt | ehm... easiest way i think is checking out moar by hand | ||
or | |||
going to the directory where moar was checked out, and reconfigure with the --asan flag | 21:17 | ||
but, as i said, you'll have to checkout moar-jit for that to work | |||
timotimo | nah | ||
--moar-opts=--asan | |||
and --gen-moar=moar-jit | |||
see, all the magic is there | |||
brrt | oh | 21:18 | |
cognome | I don't remember that from the doc | ||
brrt | what timotimo++ said :-) | ||
i have never built rakudo that way | |||
timotimo | that's because i didn't put it in the docs yet =\ | ||
cognome | yea timotimo++ brrt++ jnthn++ | 21:19 | |
brrt | :-) | ||
labels are quite a piece of work, so much is clear | 21:21 | ||
timotimo | jnthn: what would the roadmap look like to teach NativeCall about Blob? | ||
brrt | jnthn: are there any restrictions on the locations of osr deopt idxs? | ||
cognome | is there any win using the jit branch. I seem to understand that optimizations triggers very early to help finding bug. Is there any win despite that? | 21:22 | |
brrt | no, not yet | 21:23 | |
because you haven't enabled jit yet :-) | |||
i'm going to make a totally unscientific comparison of making moar with and without jit enabled | 21:24 | ||
ehm, building rakudo, that is | 21:25 | ||
cognome | hum, I restarted compiling rakudo from scratch using "standard optons" and it worked. | ||
brrt | 60s for a rakudo-without--jit, of which 27.972s in stage parse | 21:26 | |
cognome | not sure if it is a false alert or an heisenbug. | ||
brrt | hmmm | ||
and 28.136s with jit | |||
so no win.. at all :-) | 21:27 | ||
jnthn | brrt: No, though if you want to argue for one, we can make it happen. | ||
brrt | no, no need to argue :-) | ||
just wanted to know if the current check is optimal | 21:28 | ||
what would an array of labeled objects be called? | |||
labeleds? | |||
jnthn | That'll do :) | ||
brrt | :-) | ||
brrt is not so happy about building rakudo being slower with than without JIT) | 21:29 | ||
i know, artificial comparision, but still | 21:30 | ||
jnthn | Well, the i-cache in a CPU is only so big | 21:31 | |
When we're interpreting we can probably keep the interpreter and other hot things largely inside of it | |||
When we JIT, the JITted code creates competition for the icache | 21:32 | ||
timotimo | jnthn: don't we mix in stuff *constantly* during stage parse? | ||
jnthn | But there's lots we bail on, meaning we need the interpreter a lot too | ||
timotimo | isn't that how we add operators to the grammar for example? | ||
jnthn | timotimo: We better not be mutating the grammar during the parse...otherwise we have to pay the cost of loading that mutation in CORE.setting every single time. | 21:33 | |
That's why I insist we register everything in the grammar. | |||
(Like th empty set term the other day) | |||
timotimo | well, there are things we can't do at the beginning of the setting that we can do closer to the end | ||
oh | |||
that's a good point | |||
okay, so only custom operators would ever do that, and we don't have those in the setting | 21:34 | ||
jnthn | Yes, CORE.setting is not very custom. It's CORE. :) | ||
brrt | fair enough... i'm interested in seeing how it does after benchmarks + handlers | 21:35 | |
eh after extops + handlers | |||
timotimo | mhh | 21:36 | |
brrt | jnhtn: in what contexts are deopt_inline annotations actually used? | 22:16 | |
jnthn | They could be deopt_one or deopt_all | 22:20 | |
brrt | hmm... this may be my half-sleeping self, but i don't understand that answer i'm afraind | 22:24 | |
afraid | |||
jnthn | When we inline code, we concatenate the deopt tables | 22:25 | |
It doesn't at present make any effort to differentiate inlined deopt all vs deopt one | 22:26 | ||
Because so far it's not mattered | |||
There's one deopt table for all/one | |||
brrt | uhuh | 22:27 | |
jnthn | The only reason we differentiate all and one is because sp_log might lead to a guard, which wants the deopt_one annotations moved to the guard. | ||
Whereas the deopt_all must stay on the invoke no matter what. | |||
brrt | ok, i get that | ||
:-) | |||
but deopt_inline? | |||
jnthn | When we inline, we take the spesh'd bytecode of the inlinee and re-build a spesh graph out of it. | 22:28 | |
And when we hit a deopt, we note it with deopt_inline | |||
We kinda lost the information about what kind of deopt it was after code-gen. | |||
And we don't need to do anything more than update the correct offset in the table. | 22:29 | ||
So a deopt inline was either a deopt_one or a deopt_all in the inlinee at the time it was code-gen'd. | |||
Until now, this information loss hadn't shown itself. :) | 22:30 | ||
I think for your purposes, I'd assume they're a deopt_all; since they can only occur on invoke sequences anyway, your chance of false positives is low, and they are also harmless. | |||
brrt nods | 22:31 | ||
anyway, on guards, i act as if they're deopt_one | |||
jnthn | (Aside: it may be that graph.c in spesh neglects to put a basic block boundary after an sp_fastinvoke. I can't remember. It may get it right.) | 22:32 | |
Yes, on guards they will be. | |||
brrt | it neglects it, but it doesn't matter fo the jit | ||
for | |||