|
00:46
ggoebel joined
00:58
ShimmerFairy joined
01:47
ilbot3 joined
|
|||
| TEttinger | feed it snowden leaks | 01:57 | |
|
05:00
harrow joined
07:03
zakharyas joined
07:10
lizmat joined
08:23
mtj_ joined,
brrt joined
|
|||
| brrt | good moarning | 08:34 | |
| jnthn | dobre jitro :) | 08:36 | |
| brrt | iirc... jitro was late morning? | 08:38 | |
| jnthn | Yes :) | ||
| jnthn starts typing "how to make atom package" and before he could get done google was suggesting "how to make atom bomb" o.O | 08:42 | ||
| brrt | it's an interesting topic :-) | 08:43 | |
| FROGGS | jnthn: that probably just happens because you implemented DESTROY not too long ago :o) | 09:02 | |
| FROGGS .oO( $*W.^can: 'DESTROY' ) | 09:03 | ||
| jnthn | :) | 09:15 | |
|
09:42
Ven joined
09:45
FROGGS_ joined
12:57
brrt joined
|
|||
| brrt | ok, thinking about it properly, i concur that instruction selection comes after tile selection, and that it'd better be done in a preorder traversal order | 13:22 | |
| or something like that... | 13:26 | ||
| timotimo | i still don't grok MVM_ASSIGN_REF | 13:51 | |
| what i do understand is it's about serialization contexts | |||
| jnthn | It's not :) | ||
| timotimo | oh | 13:52 | |
| jnthn | It's about generational GC | ||
| timotimo | that's sc_wb, then | ||
| okay; why do we need to reload objects when we hit a write barrier? | |||
| jnthn | Right, this is just the normal write barrier | ||
| timotimo | or is that only for when we have a p6opaque? | ||
| oooh | 13:53 | ||
| these stores and restores are just because registers get clobbered | |||
| brrt | what | ||
| which registers | |||
| timotimo | that explains why it writes to rbp-0x* | ||
| TMP1 and TMP2 in the cases i'm trying to cargocult from :) | |||
| brrt | ahaaah | 13:54 | |
| timotimo | no, TMP2 and TMP3 | ||
| jnthn | The write barrier might end up calling a C function | ||
| timotimo | ah! | ||
| brrt | what jnthn says | ||
| timotimo | now there's an explanation that helps :) | ||
| brrt | hit_wb calls a function, hence the values are spilt | ||
| (temporaries) | |||
| timotimo | i'm now finally going to implement setcodeobj via the old jit | ||
| brrt | mvm_assign_ref is split in two, in a sense | 13:55 | |
| timotimo | yeah, check + hit | 14:07 | |
| bleh! | 14:10 | ||
| setcodeobj never has a known type + correct reprid | |||
| it seems like that always comes from $!do | 14:16 | ||
| bbiab | |||
|
14:32
camelia joined
15:52
lizmat joined
|
|||
| timotimo | maybe i should add a little piece to spesh that checks if there's a guard for $!do having a known type so that that won't be thrown out before jit? | 15:57 | |
| jnthn: we don't emit log instructions for the result of getattr_o; is there a good reason to keep it that way? | 16:09 | ||
| i was wrong | 16:21 | ||
| we actually do put in a log op for getattr_o and getattrs_o | |||
| darn, they log different types, but of course all have the same repr | 16:22 | ||
| FROGGS | PR 233 is quite interesting | 16:24 | |
|
16:40
lizmat joined
|
|||
| japhb | FROGGS: Feels like it should come with a mini-benchmark though. I would expect MVM{,_bigint}_radix are fast-path operations; it would be nice to avoid making them much slower (if indeed this has any significant effect). | 16:57 | |
| timotimo | perhaps a "known reprid" fact would be interesting? | 17:10 | |
|
19:59
synbot6 joined
|
|||
| dalek | arVM/jit_and_opt_setcodeobj: 0c3c8fb | timotimo++ | src/ (3 files): jit and try to opt setcodeobj alas, we pretty much always log different type objects. since the opt is only interested in REPR ID, maybe that ought to become an entry in facts? |
20:44 | |
|
22:45
TEttinger joined
22:49
notostraca joined
23:44
notostraca joined
|
|||