github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
dogbert2 jnthn: are you around? 13:13
the DU chain errors you fixed the other day are present in master in will go out with 2018.09. Is that a problem? 13:15
dogbert2 *and will go out 13:15
jnthn dogbert2: I don't think so. One resulted in an instruction not being deleted (so harmless), the other broke SSA form but was still writing correct values to correct places. 13:27
dogbert2 jnthn: thx 13:54
dogbert17 what does the following error message mean? 19:58
Unhandled exception: getlexref_*: outer index out of range
at SETTING::src/core/IO/Socket/Async.pm6:170 (/home/dogbert/.rakudobrew/moar-master/install/share/perl6/runtime/CORE.setting.moarvm:connect)
jnthn dogbert17: "Something went rather wrong" 20:41
dogbert17: I...really can't guess what
timotimo oh, hm 21:32
nope, not hm after all!
i'll now look into removing prof_allocated for arg_* and invoke_* ops being replaced by set ops 21:33
the DU chain checker is barking at me on master, is that known? for the core setting compile 21:51
jnthn Yeah, probably fixed in postrelease-opts 21:54
I know it's clean in there, at least :)
timotimo hah. i should probably base my work on that branch, then
timotimo MoarVM oops: Spesh: instruction prof_allocated missing from define-use chain 22:02
well, that's at least something
jnthn That one's on you :P 22:04
Hm, thinking about it...I didn't audit the profiler when I did the DU chain changes, I don't think 22:05
timotimo MoarVM oops: Malformed DU chain: reader prof_allocated of 3(5) in BB 8 missing 22:08
PHI r3(5), r3(19)
prof_allocated r3(5)
that looks like your change for returning
to support umltiple returns properly
jnthn Well, the fix I did was to correct a malformed DU chain 22:09
timotimo hah
jnthn It makes the PHI the original register that the invoke came back from 22:10
Uh, invoke put the return value into
So if the prof_allocated used r3(5) before it should be alright
timotimo it's the same before and after the optimization pass i believe 22:12
well, since i was going to remove that one anyway, maybe i'll adapt that to the new "return has a phi now" code 22:14
jnthn I'm am quite curious how this broke things 22:15
timotimo oh i have an idea
hum. i think i used return_bb when i should have used invoke_bb 22:16
but the error is still the same 22:17
oh, i think i see what's up 22:23
i'm trying to delete the user, but i don't know its BB 22:24
in bb 32 (0x7fffec2f5d28) killing allocated logger of ins set for operand r14(15)
maybe i used return_bb where i should have used inMoarVM oops: Malformed DU chain: reader prof_allocated of 14(15) in BB 33 (0x7fffec2f5d88) missing
is there API for "give me the BB that has this ins in it"? 22:26
jnthn No 22:27
And it'd be linear search
timotimo is there a reason not to have that?
yes, it would
jnthn So it's not really encouraged
Everywhere we need the two we carry them around together
timotimo am i allowed to add the bb of an ins to the MVMSpeshUsageChainEntry? 22:28
jnthn No, because BB merging will invalidate it 22:28
timotimo then spesh optimize will have to see the prof_allocated and figure out that it can't be from something that allocates any more
timotimo though more likely it'd go through things that wrote to relevant registers and see if perhaps it got logged already 22:29
jnthn What phase do you do this in?
Could it be suitable to do in the post_inline phase?
timotimo at the moment it's happening right as we rewrite_args and rewrite_returns
jnthn Is it being kicked out for efficiency reasons? 22:31
Or correctness?
timotimo efficiency 22:32
for that, i'd say the args rewrites are more important
because then identity should finally become just prof_enterinline, prof_leave
i'll leave the return-allocate-logger-opt out for the moment, then 22:33
MoarVM oops: Spesh: instruction box_i missing from define-use chain 22:34
huh
i wonder why there is barely any detail in this error message 22:36
ah! it happens in a different place
that's now in the post_inline pass for some reason? 22:37
removing the allocation logging made the box_i unused and that sprung a trap? 22:38
jnthn The error means that there's a box_i in the graph that's *not* in the DU chain
I wonder why the error is missing the register being read by the box_i... 22:39
timotimo MVM_spesh_usages_delete is giving me this, which was called via post_inline_pass, in the line that says "/* Box instruction becabe unused; delete. */"
jnthn Oh!
Then it's not the DU checker 22:40
timotimo "becabe" m)
yes, that's right
jnthn But the C stack tells exactly where, as you found :)
timotimo the only user in that chain was a PHI node
mst timotimo: e.g. here 23:00
timotimo rr shall help me. 23:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!