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.
Nicholas good *, bloatable6 08:21
jnthnwrthngtn: yes, ASAN is back to the usual disdain for MoarVM
(and shows no interest in timo's change either)
timo made the absolutely smallest change in compile_mastop 17:18
timo callgrinding core setting compilation to get like a comparison number but ... dang 17:32
Nicholas good *, brrt 18:10
brrt good * Nicholas
any more quests for me
Nicholas "JIT all the things"
(A joke) 18:11
seriously - keep having fun
brrt :-) 18:12
timo i mean, i'm still not sure how we'll be doing devirtualization of reprops and such in the exprjit 18:25
but that's probably not just a little weekend project 18:26
brrt it's not... I forgot what was the holdup for that 18:28
well, I recall what was my theory at least
timo probably "how to get the information were it needs to go"
my h key is acting up today
brrt the theory was to add a method to the repr to allow it to add a template
well, something like that
and then... to have some way to create an includable header file, from a template file, that you could address-and-load by name 18:29
and then the repr method would need to get the spesh graph so it could get facts
timo tis all goes in the main moarvm repo so we can probably make it hook in all the places we need it 18:30
brrt yeah
it's doable, it's just a bunch of plumbing
Makefile plumbing, too 18:31
timo the spes method on the repr already gets the spesh graph so it can check facts and such
how do we mark wat operations should go throug te repr's bonus function?
brrt ehm,... oh, I had a theory of that too; 18:32
the first input operand should be an object; and we should know the type of that object 18:33
timo don't forget our attribute related ops also take "the type that actually has the attributes" argument 18:34
but that very often just comes from a wval
timo what has to actually happen so that the expr template written for a given reprop in a given repr ends up in the right spot? 18:41
timo can we just return something specific from the function and the exprjit engine can easily do the rest? 18:42
timo i wonder if we can benefit from knowing values for some registers when they are used in templates for cases where refering to a moarvm register is more expensive than having an immediate value 18:47
m: say (2500 + 280 + 530 + 80) / 60 19:06
camelia 56.5
timo oof. almost an hour to callgrind my core setting compilation
timo m: say 2500 / 60 19:31
camelia 41.666667
brrt timo: that's mostly the idea yes; the method gets the tree, and it should be able to append its subtree for it, using templates that were generated for it 19:48
timo i think the callgrind measurement was far too noisy 22:31
timo so the exprjit repr function could return a template for the rest of the loop in MVM_jit_expr_tree_build to consume, or it could be asked to do all the remaining work by itself. I'm thinking we want to allow one of the two for common cases and the other for wen you need more control in your template? 23:36
so, a status return value and a MVMJitExprTemplate ** parameter for when the/a template should be taken from te repr's exprjit function and treated as normal 23:37
aaaanyway i have a first draft of a little bit of the C that we'd need 23:45
Geth MoarVM/exprjit_repr_api: 0d5ab06374 | (Timo Paulssen)++ | 47 files
add new function pointer to REPROps: exprjit

here a repr could output a specialized tree for a given op, based on whatever is in the reprdata and known facts from the spesh graph.		 23:50
MoarVM/exprjit_repr_api: d3949ccb1a | (Timo Paulssen)++ | src/jit/expr.c
call a repr's exprjit function if it exists

  (none exist at the moment)
timo calling all brrt's for review of this ;)

Powered by Cro and the Raku® Programming Language.

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

Thank you!