00:39 Geth joined 01:53 yoleaux joined 02:58 ilbot3 joined 03:00 squashable6 joined 03:05 AlexDaniel joined 03:39 Voldenet joined 03:57 bloatable6 joined 03:58 unicodable6 joined 04:56 JimmyZ joined 05:50 committable6 joined, statisfiable6 joined 07:04 sivoais joined 09:04 domidumont joined 09:10 domidumont joined 10:03 yoleaux joined 10:25 lucasb joined
lucasb Hello good people 10:26
In github.com/MoarVM/MoarVM/blob/mast...#L548-L551
I guess the correct way to call a sub ref in P5 is $OS_OPENBSD{cc}->() and $OS_FREEBSD{cc}->() 10:27
nine lucasb: Hi! $OS_OPENBSD{cc}() works, too, same as $h{a}{s}{h} 10:32
lucasb nine: oh, you're right. I thought that was the problem :) 10:34
I forgot about the implicit arrow between brackets 10:35
I dunno why the coderef got dumped in "Failing command: CODE(0x802884d08) -o try.o -c try.c 2>&1 " 10:37
In RT #132741
synopsebot RT#132741 [new]: rt.perl.org/Ticket/Display.html?id=132741 [BUILD] Broken on FreeBSD and OpenBSD
10:40 yoleaux joined 11:31 leont joined 11:48 releasable6 joined 12:15 AlexDaniel joined 12:36 greppable6 joined, benchable6 joined, coverable6 joined, reportable6 joined 12:45 yoleaux joined 13:05 AlexDaniel joined 14:14 bisectable6 joined 14:23 nwc10 joined 16:02 domidumont joined
nine How can a basic block that only consists of a "set r17(17), r23(16)" (without any annotations) have 2 successors? 16:25
16:36 yoleaux joined
lizmat that feels wrong, but I'm a noob there :-) 16:36
jnthn nine: Inept CFG manipulation...somewhere :) 16:38
Oh, actually 16:39
It coulda ended in decont
That was rewritten to a set
If it was also inside of a control exception region, then the extra succ is to the control exception handler
Which is not possible to reach after turning it into a set, of course
nine So we should go through the BB after doing such optimizations to recalculate succ? 16:45
jnthn I think we need in graph.c to record which succes we add as control exception flows 16:47
*succs
And then, on opts that devirtualize decont and other such invokish opts, kick out those succs afterwards
(There's a function in manipulate.c to call to remove a successor, and it cleans up the preds of the target too) 16:48
nine But we'd still need to check other instructions in the BB after devirtualizing an instruction to know if we can remove the succ. 16:50
jnthn How so?
An invokish instruction is a BB terminator
nine Oh, so there's only one of them in a BB
jnthn Yeah :) 16:51
And it will be the final instruction of the BB
nine Can there be more than one additional succ for such an invokish?
jnthn github.com/MoarVM/MoarVM/blob/mast...aph.c#L339 fwiw
I can't think of such a case 16:52
nine Then recording is just setting a simple extra field in MVMSpeshBB
jnthn Which I guess means we could get away with not keeping a list of BBs added as control edges and assuming everything except linear_next is one 16:53
But I'm...hesitant to make such an assumption.
17:04 zakharyas joined 17:29 zakharyas joined
nine Still a mystery why a basic block consisting only of "unless_i r21(7), BB(39)" can have 3 successors. And that's _before_ specialization. 18:11
Is that just due to active handlers even when the instruction cannot throw? 18:12
18:20 zakharyas joined 18:21 zakharyas joined 18:33 zakharyas joined 18:41 nativecallable6 joined
jnthn nine: Yes, I think all BBs within the scope of a control handler (not a catch one) are linked to the control handler 19:02
nine: Which is conservative :)
nine Oddly though, only adding that succ if the last instruction in the BB is marked as throwish breaks things badly 19:04
jnthn Yes, that won't suffice, at the very least because invoke_* and friends aren't marked invokish because they're actually, well, invokes :) 19:07
Note it has to be throwish and invokish and invoke at least, because invokes can invoke something that throws 19:08
19:34 Ven`` joined 19:36 quotable6 joined 19:46 yoleaux joined 19:50 yoleaux joined
nine Yep, including invokishs and invoke* makes it work 20:11
timotimo i wasn't even aware we have an invoke flag, apart from invokish 20:15
nine We don't. I compare the opcode.
timotimo oops :) 20:18
i'm no better :D
nine Ok, we may have multiple succs through multiple active handlers. So a single field will not do. 20:23
timotimo do we have the luxury of the succs themselves having only one pred?
nine I dare say that's unrealistic for a typical handler BB 20:24
timotimo oh, right, handlers
yes, indeed
oh, but wouldn't handlers have the same kind of incoming connection anyway? 20:25
from all their preds?
well, except from the initial bb i guess? 20:27
it's probably best to introduce a new field, though
nine What I need is to find out which succ is pointing at a handler, so I can remove it from the list.
timotimo yeah 20:28
jnthn nine: Yes, I was expecting you'd need a control succ list, not just one field :)
nine jnthn: that was the point of my question about more than one additional succ for an invokish. 20:29
timotimo fortunately we have the manipulation functions that can handle changing succs and their info at the same time
20:30 yoleaux joined
jnthn shop & 20:30
timotimo get to da shoppa~ 20:31
nine Would it be fair to say that a handler BB will only ever be entered through a throw? 20:39
I.e. couldn't we just add an "is_handler" flag to BBs?
timotimo that's what i meant when i said "wouldn't handlers have the same kind of incoming connection anyway" 20:44
20:51 evalable6 joined 20:54 MasterDuke joined
MasterDuke is there some (hopefully prioritized) list of JIT templates needed for the new JIT? 20:55
jnthn nine: No; last handlers jump to a point after the loop, next handlers to a point near the start/check, etc. 21:01
This is why we can optimize some of them into goto instructions
timotimo MasterDuke: i'd just run stuff and see where it says it can't do, then check out what would be next 21:03
like, if adding a single template would only give us a single more instruction, then whatever 21:04
21:04 yoleaux joined
jnthn Put another way, control exceptions often don't actually have a distinct handler 21:04
They just transfer control flow
timotimo but if one single template would let us fully template up a whole block, then cool. 21:05
on the other hand, templates that are basically just a C function call, they don't give us much room for improvement 21:06
yo MasterDuke, i gots a perl6 script that turns graph.c into a whole bunch of templates, but i think it might have bitrotted; something about the template format changing for example? i haven't actually checked, just assuming 21:07
nine This is odd. I have a spesh log that tells me that deconts got turned into sp_p6oget_o. The only place in the code base I could find for that is src/6model/reprs/P6opaque.c:1429 Yet a debug print right there never triggers for this function 21:08
timotimo nine: look at rakudo's ops 21:10
in src/vm/moar/ there's a c file that'll interest you
nine timotimo: oh thank you! I would have never found that 21:12
timotimo :)
nine Very nice! We now get nativecast from 20 down to just 4 basic blocks 21:16
timotimo oh yeah!
nine Actually....this work could even make our performance worse in the short term as the expression JIT will bail out of large BBs instead of the small ones when it may be able to compile other parts 21:20
timotimo ugh, true 21:26
Geth MoarVM/inline_in_place: c60ebd7a4a | (Stefan Seifert)++ | 6 files
Clean up handler successors after throwish ops become non-throwing
nine All the more reason to work on those templates :)
timotimo aye 21:27
we don't really have a good way to communicate stuff between jit and spesh 21:29
but we could in theory have an annotation that allows the expression jit to either just continue or restart 21:30
so like a bb border, but softer
so what was once a bb boundary would just have an annotation in the middle where the expression jit would be safe to start again, but doesn't need to stop 21:33
MasterDuke timotimo: is that script somewhere on github? 21:41
timotimo hm, i didn't put it up in the moarvm repo? :\
it's tools/parse_jitgraph.p6
337 LoC, more than i remembered
MasterDuke cool, i'll take a look 21:42
nine What could be wrong with my template for getcode? (template: getcode (idx (^getf (cu) MVMCompUnit body.coderefs) $1 ptr_sz)) 21:52
timotimo are there other templates for things that take a coderef? 21:56
nine Ah, this is the correct version: (template: getcode (load (idx (^getf (cu) MVMCompUnit body.coderefs) $1 ptr_sz) ptr_sz)) 21:58
Maybe idx just computes the address and load is needed to actually dereference it 21:59
timotimo ah, probably 22:00
nine Indeed, it's even documented :) =IDX= | =(idx reg reg $scale)= | =reg= | Compute a pointer for an index in an array 22:01
22:05 ilmari joined
nine And takeclosure seems to be: (template: takeclosure (call (^func MVM_frame_takeclosure) (arglist (carg (tc) ptr) (carg $1 ptr)) ptr_sz)) 22:08
This is actually rather simple :)
And really seems to help performance 22:09
22:09 AlexDaniel` joined
jnthn \o/ 22:10
samcv what does idx stand for?
nine index into an array 22:11
is how I read it
samcv is there a place where these are written down? 22:14
nine samcv: docs/jit/overview.org:138 22:16
samcv thanks 22:20
22:22 squashable6 joined, unicodable6 joined, committable6 joined, bloatable6 joined 22:59 SmokeMachine joined 23:11 geekosaur joined 23:20 lizmat 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!