|
01:27
squashable6 joined
01:28
reportable6 joined,
coverable6 joined,
greppable6 joined,
bisectable6 joined,
statisfiable6 joined,
bloatable6 joined
01:59
evalable6 joined
02:26
MasterDuke joined
02:58
ilbot3 joined
03:17
MasterDuke joined
03:22
colomon_ joined
04:29
japhb joined
07:13
domidumont joined
07:18
domidumont joined
07:42
brrt joined
|
|||
| brrt | good * #moarvm | 08:01 | |
|
08:11
committable6 joined
|
|||
| brrt | i'm thinking how i want to implement the const-copying trick in the register allocator | 08:16 | |
|
08:46
brrt joined
09:07
zakharyas joined
10:28
zakharyas1 joined
10:30
japhb joined
11:02
brrt joined
|
|||
| dogbert2_ | brrt: did you see github.com/rakudo/rakudo/issues/1483 ? | 11:06 | |
| brrt | did not | 11:07 | |
| dogbert2_ | initial findings make it look as if the JIT might be involved | 11:08 | |
|
11:11
zakharyas joined
|
|||
| brrt | yeah, i see it | 11:16 | |
|
11:24
brrt joined
11:27
AlexDaniel joined
|
|||
| timotimo | floor_n is a juicy target for jitting to make this code faster: perl6 -e'my @a = "a".."z"; for ^500_000 {my @b = @a.roll(20)}' | 12:45 | |
| dogbert2_ | brrt: any theories? | ||
| timotimo | it has 82% speshed-but-not-jitted frame calls | ||
| brrt | ouch | 12:46 | |
| timotimo | 73% call frames thrown out by inlining, but that makes any jit bail more extreme | ||
| brrt | no theories, no | ||
| haven't looked at it in detail now | |||
| timotimo | i guess we could implement floor_n with a coerce_ni and a floor_i to have an impl immediately | ||
| i don't have any time today, though | 12:47 | ||
| dogbert2_ | I guess the gdb output isn't enough (but perhaps a clue) | 12:51 | |
|
14:32
japhb joined
14:42
japhb joined
14:44
zakharyas joined
14:46
zakharyas joined
15:10
zakharyas joined
16:05
brrt joined
16:26
zakharyas joined
|
|||
| brrt | expr jit can bisect it | 16:37 | |
| i can fairly probably debug this | 16:57 | ||
|
16:58
japhb joined
17:26
domidumont joined
17:34
zakharyas joined
17:41
samcv joined
18:08
zakharyas joined
18:16
AlexDaniel joined
21:00
Kaiepi joined
21:30
Ven`` joined
22:12
bart__ joined
|
|||
| bart__ | good * | 22:50 | |
| brrt | oh boy, there's deopt_inlines on the sp_getspeshslot | 22:55 | |
|
23:07
brrt joined
|
|||
| brrt | weird thing i'm seeing, is double restore of spilled value | 23:15 | |
| ok, i've spotted the miscompile in question | 23:26 | ||
| jnthn | brrt++ | 23:27 | |
| brrt | github.com/rakudo/rakudo/issues/1483 check it out | 23:29 | |
| see the mov rax, [rbx+... | |||
| those are spilled-value restores | |||
| except | |||
| they should never be using rax | |||
| rax is register 0, and it's illegal to allocate | 23:30 | ||
| (well, within my system. other compilers can allocate rax just fine) | |||
| but i use it as the scratch register | |||
| now that would most plausibly happen, if the live ranges used for that 'spill restore' are never allocated for at all | 23:31 | ||
| now all i have to do is figure out why that is :-) | |||
| but my guess is somewhere between not being added to the spill list, or not being processsed because the loop enters prematurely | |||
| also, earlier in the code i'm seeing restores being inserted twice | 23:32 | ||
| i wonder what's up with that | |||
| jnthn | Sounds like it's getting itself a tad confused | 23:33 | |
| brrt | yeah | ||
| i was attempting to optimize that to never spill for tiles that hold constant values (but to copy them instead) | |||
| this morning | 23:34 | ||
| it was more complex than i had thought :-) | |||
| jnthn | Yeah, those two dead writes into rax would be wrong dodgy even if rax was legal in our JIT's scheme | ||
| brrt | so one of the reasons why it could get confused, maybe, is that they are joined over an IF node as well as over a COPY node | 23:36 | |