brrt good * #moarvm 08:01
brrt i'm thinking how i want to implement the const-copying trick in the register allocator 08:16
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
brrt yeah, i see it 11:16
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
brrt expr jit can bisect it 16:37
i can fairly probably debug this 16:57
bart__ good * 22:50
brrt oh boy, there's deopt_inlines on the sp_getspeshslot 22:55
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!