01:25 vendethiel joined 02:00 colomon joined 03:26 colomon joined 03:45 lizmat joined 04:10 TEttinger joined 04:25 vendethiel joined 05:57 vendethiel joined 06:17 FROGGS joined 06:47 zakharyas joined 07:10 vendethiel joined 07:38 FROGGS joined 07:39 vendethiel joined 08:09 vendethiel joined 08:36 vendethiel joined 09:33 vendethiel joined 10:56 Ven joined 11:24 brrt joined
brrt it occurs to me that it would be correct to a): spill fully at every 'spillish' IR op, (call/if/when) 11:31
b): dump all registers allocated within each conditional 'block' 11:32
.... or, put in other words, a expression tree is bigger than a basic block 11:43
11:55 colomon joined
brrt if we're looking at the minimum spill extent, then i'd note that they 'bubble up' 12:00
a single fully-destructive spill deep in a branch somewhere - i'm looking at write-barriers in particular - destroys all registers all the way up to the highest branch 12:01
this, in other words, sucks 12:02
but the question 'what to spill' is largely independent from 'where to spilli t' 12:03
it
and is also indpendent of the question 'to which location'
so properly considered, there are three questions 12:05
a): where is it necessary to spill registers
b): which registers are necessary to spill
c): where should we spill the registers to 12:06
c can be solved by figuring out where a certain node stands for 12:07
i.e. if it does or does not stand for a local 12:08
a local value can always be spilled to it's local register, a temporary value needs to be spilled to stack space 12:12
12:26 brrt joined
jnthn brrt: Why are write-barriers fully destructive, ooc? 'cus they involve a call? 12:28
brrt aye 12:30
annoyingly, only a branched call, and not necessarily a likely one at that
but i... hmmm
oh
of course, i can also compile 'restoration' code post-call
within the branched segment, that is 12:31
e.g if foo: spill; call; restore; end rather than spill; if foo; call; end; restore 12:32
is that much more complex? hmmm.... yes-ish, but not that much
as in, it doesn't require any knowledge that any of the other spilling schemes don't also require 12:35
i can, of course, spill completely defensively 12:40
as in, spill all values upon an if or call
spilling is easily the hardest problem i've seen so far :-)
jnthn Well, there's always the option of doing the simple/obviously correct thing first, and then the cleverer thing once that's working 12:47
brrt that is true 12:49
the simple/obvious thing would be to emit a spill before a branch, after a branch, and before a call 13:00
noting that i don't want to do loops within the expression tree themselves 13:01
that would go so far from the notion of a loop as to be pointless :-)
s/loop/tree/ 13:03
13:11 LLamaRider joined 13:13 oetiker joined
brrt i think my theory of a generic traverser was quite wrong 13:19
13:20 colomon joined
brrt or... not 13:21
hmm 13:22
FROGGS jnthn: I can do that return_* stuff only from within that frame, right? 13:23
ahh, nvm, perhaps 13:24
jnthn FROGGS: Right 13:32
FROGGS: We could set up a leave handler around the whole block maybe
That does a getpayload/return_o
Then as we unwind towards the block we'll run all the needed LEAVE phasers 13:33
brrt yay JIT news :-) 13:34
FROGGS where would we add the leave handler? when handling the exception? 13:35
brrt v8project.blogspot.nl/2015/07/diggi...n-jit.html
looks *suspiciously* like SSA
13:37 JimmyZ__ joined
jnthn FROGGS: Well, I was thinking it's just a normal entry in the exception handler table...or is thatnot what you meant? 13:40
Actually I don't understand the question... :)
Do you mean "does the QAST->MAST emit it for every block"? 13:41
I don't know that can work 'cus we need a chance to enforce type checks
In fact, for routines we'd really like return and leave to hit the same handler... Hm.
We also have this bug:
m: sub foo($x = return 42) { }; say foo() 13:42
camelia ( no output )
jnthn I've no idea what that actually returns from. But I think we can agree it's bust...
I think we may need a different factoring for attaching the return/leave handlers anyways. 13:43
FROGGS I don't get why I don't find the code_ref of the block... 13:53
jnthn Me either...
It's still on le call stack, yes?
FROGGS yes, I think so 13:54
I have: do { &?BLOCK.leave }
jnthn Can you try it with --optimize=off (to Perl 6)? 13:55
FROGGS no luck 13:56
jnthn Hm, that's one hypothesis out then
FROGGS hmpf, we also do not care about labels attached to blocks yet 14:02
does normal blocks have frame handlers? 14:05
jnthn Any MoarVM code block can have them 14:06
uh, frame 14:07
FROGGS okay, we do not attach the labels to these atm... 14:08
14:14 vendethiel joined 14:39 vendethiel joined
brrt bbiab 14:41
15:02 zakharyas joined 15:29 brrt joined 16:15 dalek joined 18:22 nebuchad` joined 18:25 hoelzro_ joined, btyler_ joined 18:32 dalek joined 18:57 tadzik joined 19:08 flussence joined 19:09 flussence joined 19:11 flussence joined 19:39 _longines joined 19:49 ggoebel joined 19:52 timotimo joined, retupmoca joined, hoelzro_trying_w joined 20:10 zakharyas joined
nwc10 A new blog post: blog.pyston.org/2015/07/14/caching-object-code/ 20:38
previous was on 2015/02/24 20:39
20:50 TEttinger joined
jnthn "we JIT 66 python functions which takes about 1.4secs" 20:53
That cost surprises me a little. 20:54
Caching JITted code is a nice idea, though. Maybe we can borrow that some day. But yeah, it needs care. 20:59
I wonder where they keep the cache, and if there are any security worries. I think not because of the hashing they do
cognominal what is the purpose of nqp::markcodestatic? 21:20
I want to document some nqp:: ops about coderef, but this one I can't figure out (yet) 21:21
it seems related to serialization
[Coke] cognominal: in docs/ops.markdown ? 21:25
cognominal I want to document ops missing fromm ops.markdown :) 21:26
hopefully, nqp/t/03-closures.t seems helpful as example 21:28
[Coke] right, just making sure that's where the docs are going. awesome, thanks! 21:31
jnthn cognominal: It's about identifying the "original" code object from any closure clones of it. 21:32
cognominal Also p6 ops are undocumented to.
jnthn And yes, we care for serialization purposes.
cognominal ok, that makes sense. 21:33
jnthn++
22:08 flussence joined 23:02 Ven joined 23:49 cognominal joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!