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
nine How can a basic block that only consists of a "set r17(17), r23(16)" (without any annotations) have 2 successors? 16:25
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.
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
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
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
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
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
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!