Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Geth MoarVM: MasterDuke17++ created pull request #1746:
Add a bunch of `*_u` stuff
02:07
MasterDuke hm. i wonder if we need e.g., add_u? 02:27
timo1: any idea how i could also get the checkarity and param* ops optimized away here gist.github.com/MasterDuke17/731d4...sh-log-L67 like they are in the `int` version? 02:35
[Coke] is there a JIT if we're running in arm64? 02:36
or just x86_64 (on mac)
MasterDuke no jit on arm 02:42
timo1: oh, i think it's back to that arg_type business. so what is my pr missing? 02:46
nine: interestingly, that t/09-moar/01-profilers.t used to be trivially reproable for me, but now it's been running 750+ times without a fail (with spectests running in the background) 03:52
timo1 we need the param_rp_u op to be able to handle a native int (not uint) flag in the callsite (and probably the rp_i to support a native uint flag) 08:50
it's possible that we are actually supposed to have a uint flag in the callsite there, not sure if that's true. that woul mean a change in rakudo probably. perhaps in the piece that optimizes a for loop over a range? 09:40
lizmat yeah, afaik that only looks at the primspec of native ints ? 10:22
timo1 so --target=optimize for the example code with int and with uint could be insightful 10:52
beyond just looking at the generated moar instructions
timo1 we might need both the moar changes MD already put in the PR and an additional change in rakudo's optimizer 10:53
maybe also a bit more inside spesh 10:54
upon a quick glance it looks like the for-over-range optimization activates, but it probably generates an int register where it could know that the pointy block takes a uint 10:59
slightly confounding issue: for this optimization we start the counter register at -1
if we want to continue using this, we will have to make sure that whatever we do we properly overflow from whatever -1 turns into back to 0 or we get very funky results from very benign looking code 11:00
possible further point of research: what happens if we put an at-the-integer-limit value as the start or end of the range we for over, since we have the -1 at the start value, the -1 at the end value, and checks and whatnot 11:01
do we ever accidentally make a 0 steps for loop when the start and end value are fine before the optimization but become funky after? 11:02
lizmat timo1 assigning -1 to a uint and then incrementing yields 0, so there no issue there afaik 11:05
m: my uint $a = -1; say $a; $a++; say $a
camelia 18446744073709551615
0
timo1 this amuses me: the symbol for NL puts an nl at the top and an L at the bottom, so NL followed by 0 followed by another NL reads like NON LOL 11:25
lizmat ␤a␤u␤a␤u 12:14
timo1 very good 12:17