00:04
woolfy joined
01:36
FROGGS_ joined
01:48
btyler joined
06:45
woolfy left
06:58
FROGGS joined
07:07
zakharyas joined
08:49
lue joined,
woosley joined
08:52
cognominal joined
09:06
donaldh joined
10:32
donaldh joined
10:35
cognominal__ joined
10:55
cognominal__ joined
11:50
cognominal__ joined
12:00
FROGGS joined
12:05
brrt joined
12:22
brrt left
12:26
brrt joined
12:42
jnap joined
13:34
btyler joined
17:37
FROGGS[mobile] joined
17:50
zakharyas joined
|
|||
dalek | arVM/spesh_nameds: 6efc152 | jnthn++ | src/spesh/args.c: Collect, rather than bail on, named param ops. Currently don't do anything much with them, but this does allow us to spesh the other params. |
18:25 | |
19:34
brrt joined
|
|||
brrt | \o #moarvm | 19:53 | |
FROGGS | hi brother | 19:55 | |
hi brrt | |||
-.- | |||
dalek | arVM/spesh_nameds: 3c2f0a0 | jnthn++ | / (6 files): Add spesh op for marking a named arg used. |
20:01 | |
arVM/spesh_nameds: 42f3e23 | jnthn++ | src/spesh/args.c: Turn some named args into indexed lookups. This avoids checking string names match up. Only done for provided required named args where types match so far. |
|||
jnthn | o/ brrt | ||
brrt: More distractions, or quiet JIT hacking today? :) | |||
brrt | a bit of both :-) | 20:03 | |
jnthn | :) | ||
brrt | i've been reading the 'compilers' book again | ||
on codegen | |||
does anybody use MVM_platform_alloc_pages? | 20:10 | ||
jnthn | brrt: not afaik; I didn't even know it existed :) | 20:13 | |
brrt: Somebody musta been thinking ahead... :) | |||
brrt | i'm ambivalent about it | 20:18 | |
on one hand, it probably works (and it might not) | |||
an on the other hand, it almost does what i want - that is, i need memory to be writable or executable, not both | |||
jnthn | brrt: Since nothing else is using it and it was probably put in speculatively, just change it into what you need. | 20:19 | |
brrt | on the third hand, i can change it into what i need | ||
:-D | |||
ok, its time i make subgoals here | |||
what i want to reach, optimally, this week: JIT compile 'hello world' | 20:20 | ||
jnthn would settle for "add two numbers" this week :) | 20:21 | ||
But "hello world" is a fine goal too ) | |||
brrt | i would settle for that too, but one has to keep ambitious goals :-) | 20:22 | |
jnthn | I'm not sure one is harder than the other; both would seem to need some basic register operations and basic ability to JIT calls to C functions :) | ||
brrt | adding numbers doesn't need the calling c functions | 20:23 | |
jnthn | return_i does :P | ||
Well, naively anyway. | |||
brrt | really? oh.. that is ok i guess | ||
jnthn | Anyway, yes, subgoals sound good. | 20:24 | |
bbi10 | 20:41 | ||
brrt | brrt-to-the-future.blogspot.nl/2014...goals.html - ok, see you then | 20:48 | |
oh, i've forgotten quite a few subgoals | 20:50 | ||
- attach jitted code to MVMStaticFrame | |||
jnthn back | 20:54 | ||
dalek | arVM/spesh_nameds: 8c8f5cb | jnthn++ | src/spesh/args.c: Handle optional named args in spesh also. |
20:55 | |
jnthn | brrt: MVM_can_jit_graph(MVMSpeshGraph*) | 20:56 | |
brrt: Note that we pass tc to pretty much everything... | |||
brrt | yes, i wanted to ask about that | 20:57 | |
hmm | |||
i guess it won't hurt :-) | |||
jnthn | You need it for all kinds. | ||
brrt | why not just put it into a global variable? :-p | 20:58 | |
jnthn | Anyway, convention is to always pass it as first arg. | ||
Because it's per thread. | |||
brrt | i was kidding | ||
jnthn | :P | ||
(Also, the MVMInstance thing at the top is *meant* to mean we can have multiple MoarVMs in one process...) | 20:59 | ||
brrt | i'm ambivalent on whether we should put MVM_can_jit_graph in the arch-specific files or not | ||
jnthn | That's more a question of "can we make it into a JIT tree"... | ||
brrt | something embedders of all types will be happy to have | ||
hmm | |||
jnthn | In fact... | ||
brrt | i can imagine a state wherein we can compile some things for x86_64 but not for arm | ||
jnthn | MVM_jit_try_make_jit_tree that returns NULL if it fails is perhaps even better | 21:00 | |
If you see something you can't JIT, bail out | |||
Then it removes a pass over the graph. | |||
Yeah, true. | |||
brrt | i'm not worried about doing a one-pass algorithm right now | ||
i'll worry about that in due time | |||
:-) | |||
jnthn | True, but you might want to worry about writing less code :) | 21:01 | |
brrt | that is true | ||
ok i'll go with that suggestion (MVM_jit_try_make_jit_tree) | |||
jnthn | And a thing that tries then bails is less code than a thing that sees what is possible and then another that does it and explodes if it disagrees with the first. | ||
brrt | that is also true | ||
jnthn | The potential for disagreement being the longer-term bug source... | ||
brrt | oh, i know another thing i've forgotten | 21:02 | |
split out mvm_spesh_alloc | |||
jnthn | ah, yes | ||
brrt | that said, where should it go? in core? | ||
doesn't seem very core-ish to me | |||
jnthn | Add a src/util/ perhaps, if many things will use it | 21:04 | |
brrt | i'm somewhat inclined against 'util' directories as the question is - useful to whom? and why can't these things get proper names? | 21:05 | |
jnthn | Yeah... | 21:06 | |
Well, so far I've tended to not share stuff much across subsystems :) | |||
Could just stay in spesh... | |||
brrt | that seems fair enough for me now | 21:07 | |
it is always possible to refactor | |||
[Coke] introduces brrt to his codebases at work! | 21:10 | ||
brrt | well, it's always possible to refactor, unless there's a manager arround | 21:12 | |
jnthn | Some code bases are just actively hostile to it. | 21:14 | |
brrt | i know, i can't quite explain why | ||
[Coke] | mine have few tests; hard to know you're not breaking anything. :( | 21:15 | |
brrt | thats part of it i guess | 21:30 | |
dalek | arVM/spesh_nameds: cdf5c71 | jnthn++ | src/spesh/args.c: Add guards/facts for named object args. |
21:31 | |
jnthn | And le branch hurts no spectests or NQP tests, so merge time I think :) | 21:34 | |
timotimo | yays | 21:35 | |
that ought to lead to much more run time of the spesh_diff tool :\ | |||
we need to get moarvm a bunch faster again :P | |||
to keep up, i mean | |||
brrt | moarvm is going to fly as far as i'm concerned | 21:43 | |
timotimo | well, let's hope so :) | 21:44 | |
jnthn hopes so :) | |||
Next tasks for me: guard check elimination when we know exactly what we're calling. | |||
This is also a precursor to inlining. | |||
brrt | hmm... interesting | 21:45 | |
jnthn | Which I plan to look at over the weekend. | ||
dalek | arVM: d9ad0cf | (Timo Paulssen)++ | docs/bytecode.markdown: Spec callsites storing named argument names. |
||
MoarVM: acf754b | jnthn++ | src/core/callsite.h: | |||
MoarVM: Prepare MVMCallsite for storing named arg names. | |||
jnthn | oh noahs... | ||
timotimo | noah's flood? | ||
FROGGS | You killed dalek! | ||
jnthn | ;) | ||
brrt | lol | ||
21:45
dalek joined
|
|||
jnthn | Anyway, will work on the check elimination tomorrow, along with some async stuff :) | 21:48 | |
timotimo | that does sound nice | ||
brrt | yes | 21:49 | |
timotimo | we're doing a bunch of guards that just run into nothingness, afaict | ||
can we somehow annotate that we rely on something to be concrete etc etc? | |||
jnthn | "run into nothingness"? | ||
As in, aren't depended on? | |||
timotimo | well, is a guardconc needed | ||
for example | |||
yes | |||
jnthn | Yeah, that's a remaining todo. | ||
timotimo | good to know :) | 21:50 | |
i'm going to have | |||
some dinner now :) | |||
jnthn | I've realized a few things about the way I did spesh_log that I don't like much, though... | ||
timotimo | happy hacking and/or sleeping | ||
jnthn | So will address that before dealing with the guard use tracking as it'll simplify it. | ||
timotimo | care to elaborate a tiny bit? | 21:51 | |
jnthn | It may be possible to structure things so the interp always records and thus eliminate the log insertion phase. | 21:53 | |
Though not entirely sure that's wise yet. | |||
Anyway, that may be an overkill thing to change. | 21:55 | ||
timotimo | always records? o_O | 21:56 | |
that's no performance hit? | |||
21:56
donaldh joined
|
|||
jnthn | timotimo: May be less of one than what we do today; remember that everything hot is either specialized into stuff that doesn't hit the recording versions of things. | 21:59 | |
...or JITted (in the future :)) | |||
timotimo | oh | 22:00 | |
well, or it's inside somthing the spesh is rejecting, perhaps? | |||
brrt: you still have MVM_can_jit_graph in there | 22:01 | ||
in your blog post that is | |||
and also i don't understand what the MAST is doing in the middle of that - or rather: so close to the end | |||
brrt | well... good question | 22:02 | |
i need a specific sequence of MoarVM codes to know i can compile them | 22:03 | ||
right | |||
so if i take an nqp program - any nqp program - the complexity of that mast tree is much greater than minimal | |||
which means that i spend much more time getting all the operations to compile /before/ i can prove the principle | 22:04 | ||
thus, i need to build a simple test that makes a very simple mast tree and forces jit compilation on it | |||
timotimo | ah! | 22:05 | |
it looked like you were trying to turn the spesh graph into a mast tree and then into machine code from that | |||
gotta go now :) | |||
brrt | sleep well :-) | ||
jnthn | o/ timotimo | 22:06 | |
22:07
sergot joined
|
|||
timotimo | i'll be back after noms | 22:14 | |
brrt | oh, ok :-) | 22:15 | |
nom well, then | |||
i'll be off now | 22:18 | ||
22:18
brrt left
|
|||
dalek | arVM/moar-jit: e91b799 | (Bart Wiegmans)++ | src/ (5 files): Intermediate work, doesn't do anything useful, just thinking out |
22:25 | |
jnthn | Heading off also | 22:29 | |
'night | |||
FROGGS | gnight | ||
22:44
woolfy joined,
lizmat joined
22:51
lizmat joined
23:32
jnap joined
|