github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
samcv AlexDaniel, should probably release it sometime tonight i think 09:29
lizmat dmitrysoshnikov.com/courses/essenti...ollectors/ 11:59
timotimo so there's still this case where nqp::if($!foo, ...) will compile the attribute in attributeref context; it's likely that spesh can figure this out, but i'm wondering if it shouldn't be rakudo's static optimizer that should know to change the scope from attrref to attribute in cases like this 13:16
i'm just not sure what the reliable set of checks would be to find when that's okay and when it's not 13:17
there's already a little branch for nqp::if($i, ..., ...) when $i is a lexicalref known to be native 13:22
it turns the if into an isne_i with 0 which should be a cheaper check than boolifying the number i guess?
though perhaps spesh makes the difference go away, too
MasterDuke but if we can optimize before it even gets to spesh that's only ever a good thing right? 13:25
timotimo i'd say "it depends"
if we save time in the optimize stage of compilation, that's code that runs in sequence with other stuff, whereas spesh runs in parallel
and spesh knows to only optimize code that's actually being run, though optimizing everything is probably worth it when precompiling the core setting at least 13:26
MasterDuke maybe we could be smarter/do more with the static optimization levels. e.g., be more aggressive when pre-compiling, default to less so with the option to turn it back on for command line scripts 13:29
timotimo yeah, i believe the core setting already has a higher default optimization level anyway 13:30
just not too many checks for what optimization level is active in the optimizer's code 13:31
anyway, i got a small patch for the lexicalref thing; i've extended it to attributeref, i've removed the requirement that it has to have an else block (but only if it's in void context), and maybe localref can also turn into local here. 13:33
but first, a spectest
well, it passes all spec tests ATM 13:46
jnthn timotimo: A lot of the attr => attrref stuff is taken care of in code-gen, I think 13:53
timotimo OK. it wasn't in this case, but the optimizer now gets it :) 15:03
this case refering only to if/unless/while/until
but only if the attribute/lexical/local is the direct child of the op 15:04
there's many more that have the form "blah while $foo++ > $bar" that this won't catch, though i haven't checked if they also use refs everywhere 15:05
MasterDuke timotimo: huh, looks like i never added smrt_intify support to src/spesh/optimize.c 19:13
or was there something you did/were going to do after i added the smrt_intify op?
timotimo um, maybe there was 19:14
i don't remember now :o
MasterDuke something related to this comment maybe? github.com/MoarVM/MoarVM/blob/mast...#L943-L946 19:29
direct invokes?
brrt \o 20:02
nwc10 o/ 20:05
timotimo o/
brrt I'm nearly done with floating point comparisons! 20:10
timotimo heck yea
brrt I started, for a change, actually reading the intel documentation, and it turned out to be readable
timotimo well, it better be 20:11
MasterDuke timotimo: this this looks reasonable? gist.github.com/MasterDuke17/46afe...e85872098e
timotimo i think the if/elsif with the new_ins->info needs more checks, too 20:12
MasterDuke oh? 20:13
timotimo though not sure what the stuff right before that is, maybe it excudes the possibilities of is_strify on a string register?
is_numify checks if the register type is num; if so, it becomes set, if not it becomes coerce_in
MasterDuke it's annoying, i know i implemented this before. maybe it's sitting in a local branch on my desktop 20:14
timotimo yeah, or perhaps in a stash even 20:15
MasterDuke that code is in the `else if (!is_strify && (REPR(facts->type)->ID == MVM_REPR_ID_VMArray || (REPR(facts->type)->ID == MVM_REPR_ID_MVMHash))) {` branch 20:16
timotimo ah, ok 20:17
it's kind of annoying that you can't just "show more context" for patches like that
...
if i have some extra extra time soon, i could perhaps come up with something a userscript could do
until then, theoretically, linkify could already get you one step closer 20:18
until then, i think the patch looks good? 20:24
MasterDuke cool. i'm in the middle of a spectest now
brrt should LOAD and CONST get a type parameter? 20:52
that would probably be enough to type-infer the rest of the operands 20:53
Geth MoarVM: MasterDuke17++ created pull request #1133:
Jit and spesh optimize smrt_intify		 20:57
MasterDuke whoops, accidentally had spectests running in two different terminals. no wonder this laptop was dragging... 20:58
can captureposarg_n easily be jitted? or is that one of the problematic ones? 21:01
hm, *_i and *_s are jitted, maybe i can just crib from them... 21:03
brrt you probably can, we store them in a uniform buffer 21:06
MasterDuke huh, there's no MVM_args_get_required_pos_num 21:08
brrt: btw, why the difference between github.com/MoarVM/MoarVM/blob/mast...dasc#L1079 and github.com/MoarVM/MoarVM/blob/mast...dasc#L1099 ? 21:10
brrt MasterDuke: what difference exactly? 21:12
MasterDuke and why is there only MVM_args_get_pos_num, not *_(int|str|obj) ?
brrt I'm not sure, they were added a bit haphazardly, I think
timotimo that could be for number of arguments, not get a positional num argument? 21:13
MasterDuke the '&' before the function name in one, but not the other
timotimo the & is technically redundant
MasterDuke looks like MVM_args_get_pos_num takes a "require" parameter, instead of having _require_ and _optional_ versions 21:15
timotimo gnite, maybe 21:16
brrt gist.github.com/bdw/5c942afa18cfdf...a8ccd2a12c 21:18
MasterDuke later. think i'm going to go watch an episode of jessica jones season 3 myself before sleep. will try and come back to captureposarg_n tomorrow
brrt can anybody run this and see what result they get
\o timotimo
sena_kun brrt, result is OK for me, any other info you might want? 21:19
brrt NOT OK for me
timotimo not ok
brrt wtf
MasterDuke NOT OK for me
timotimo ha
it uses islt_i for that
sena_kun I am on vanilla 03.1
brrt timotimo: what?
MasterDuke OK with 2018.12, NOT OK was HEAD
ugexe OK for me on blead 21:20
timotimo so everything in nqp is normally num magic, but with a < you'll actually get an int op
mathic* i guess
MasterDuke oh yeah, result my recent merge i guess
timotimo use --target=ast or --target=optimize to see it
brrt that's... surprising 21:21
MasterDuke OK on HEAD if i use nqp::islt_n(0.125, 0.126)
brrt has a distinctly unamused face 21:23
MasterDuke: why?
MasterDuke i'm going to change what timotimo said to "everything in nqp *used to be* num magic, but now it's int behavior" 21:24
brrt: fixes some bugs around nums not being able to represent all valid integers, should be faster, etc. 21:25
brrt I mean, why don't we 'just' infer the correct type 21:26
MasterDuke does NQP ever infer types like that? 21:28
Geth MoarVM/jit-expr-float: dd9629d01c | (Bart Wiegmans)++ | 8 files
[JIT] Support floating point comparisons

Needs some debugging, doesn't always give the right answer.		 21:30
brrt it could... it's not a hard job
anyway, that's for another day maybe
brrt zzz 21:31
MasterDuke github.com/perl6/nqp/blob/master/s...r.nqp#L821 i "just" changed the op from `islt_n` to `islt_i` 21:31
masak had some thought about detecting the problem situations in rakudo that this caused, maybe that's what he's thinking 21:32
but brrt++, looking forward to the float jitting 21:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!