02:08 tokuhiro_ joined 02:18 FROGGS joined 02:23 FROGGS_ joined 05:01 BinGOs joined 05:04 flaviusb joined 05:09 _longines joined, vendethiel joined 05:22 Peter__R joined 05:23 Hotkeys_ joined 06:02 FROGGS_ joined 06:07 TimToady joined 06:43 domidumont joined 06:59 domidumont joined 07:02 domidumont joined 07:06 nebuchadnezzar joined 07:27 FROGGS joined 07:37 colomon joined
nwc10 ASAN fails after test 32 in t/spec/S32-str/encode.rakudo.moar paste.scsys.co.uk/501579 07:43
I *think* that it used to fail earlier
oh wait, I may not be current 07:44
OK, that was the earlier. Now we make it to test 36 08:11
paste.scsys.co.uk/501580
08:19 JimmyZ joined
nwc10 OK, we're failing in the last subtest of test 36: paste.scsys.co.uk/501581 08:31
08:34 zakharyas joined 08:52 colomon joined 08:58 kjs_ joined 09:49 brrt joined
brrt good * #moarvm 09:51
i have some exciting news
even-moar-jit can now pass the nqp test suite 09:52
jnthn :D
\o/
brrt++
ASAN barf is in UTF-16, which we know is bust 09:54
But nice we have an ASAN reminder... :)
brrt yes, ASAN++
of course i have to qualify that by saying that i've removed all sorts of interesting stuff from the templates in order to get that to work 09:55
so there is still a lot of broken and unfinished
but at least i have something to build on
a minimal base, as it were
which hopefully will break the cycle of frustration 09:56
(i'll have to push later today, as my $code-laptop cannot connect to the internet at $study-office 09:58
jnthn brrt: Yes, having something that works to build on is always good 10:01
brrt now i want to attack the tiler linearisation problem; after that the offline register allocator; and somewhere in between the implicit cost computation 10:03
maybe you can help me a bit with the latter?
you know maybe a bit how i compute the tiler tables?
well, i need somehow to add the cost of e.g. (load reg) to (add reg reg) in case i can compile both (add reg (load reg)) and (load reg); (add reg reg); 10:06
jnthn hazily remembers talking about this before
brrt i can of course only generate that if the second child of those is a (load reg) tile of some sort
yes, i've been banging on about it for quite some time 10:07
jnthn It becomes an optimization problem rather than a simple compare two numbers problem?
brrt so, there's the thing, i first find all possible combinations of rules (e.g. (add reg reg) combines with (add reg (load reg)) but not with (sub reg reg))'
in principle it is still a compare two numbers problem, the problem is how to arrive at the numbers 10:08
correctly
jnthn ah
OK, so it's not as bad as I feared :)
brrt :-)
jnthn Though yeah, those numbers are potentially interesting in so far as instruction scheduling may partially influence them too?
brrt yes, that is true
although i have opted to neglect that for the time being 10:09
in fact, this tiling approach is unviable if we include instruction scheduling
although limited instruction reordering may be possible, it cannot guarantee an optimality under that constraint; but i can't claim to fully understand that topic, so i may be wrong 10:10
jnthn It may be easier to peephole anyway
brrt instruction scheduling you mean? 10:11
jnthn yeah
brrt hmmm
ok, i'll save that thought for later :-)
jnthn :-)
Yeah, it's certainly for later
brrt in fact, at current constraints, i assume the optimal rule for an optimal desired symbol can be always computed statically 10:12
i.e. i want my add node to yield a reg, and given that i can compile (add reg reg) and (add reg (load reg)), i can statically determine which one of these ought to be cheapest
so for that purpose i use a table 10:13
it is the computation of this 'minimum-cost' table which is the trouble
10:15 domidumont joined
brrt this.. should be a simple problem, since i know what combinations-of-rules generate the ruleset refering to (add reg reg) and (add reg (load reg)); i need those combinations for tiling correctly in the first place 10:15
(these combinations are what makes the table so large, by the way)
i just can't figure out how to generate that table .. or how to walk the created table 10:17
10:17 domidumont joined
brrt hmmm 10:18
maybe it's simpler than i think
once i have the table, i can reverse it; that is generate all combinations of rule-and-child-rulesets which generate a given ruleset
these child-rulesets have rules which by themselves have a cost
although, of course, the 'hidden' cost of these rules is then not calculated... so maybe i need to iteratively calculate it again 10:19
jnthn What's the "key" used to index into the table? 10:28
brrt into the tiler lookup table? that is head, ruleset-for-first-child, ruleset-for-second-child 10:29
jnthn No, the proposed cost table
brrt iirc, the intermediate table has these hashed into a single key, the final table is nested
jnthn Or you'd include them in the tiler lookup table?
brrt oh, that key
that's ruleset, symbol-name
e.g. ({1,2}, reg) 10:30
the tiler lookup table is for selecting rulesets; the cost-table is for selecting rules-out-of-rulesets, and there is a third table which maps selected rules to the required children-symbols, which is then used to lookup the rule in the second table 10:34
dalek MoarVM/even-moar-jit: cd73e63 | brrt++ | src/ (5 files): 12:43
MoarVM/even-moar-jit: Let expr tree build consume an iterator
MoarVM/even-moar-jit:
MoarVM/even-moar-jit: This allows us to safely break a basic block and let the common
MoarVM/even-moar-jit: graph handling logic deal with difficult cases. This version
MoarVM/even-moar-jit: can run nqp make test, and, I presume, use OSR correctly.
MoarVM/even-moar-jit:
MoarVM/even-moar-jit: Also fix a bug (and special case) of the inc_i and friends;
MoarVM/even-moar-jit: treating a read-write operand simply as a write operand
MoarVM/even-moar-jit: is much simpler.
MoarVM/even-moar-jit:
MoarVM/even-moar-jit: There are still plenty of things missing! But at least, and for
13:32 TimToady joined 15:37 tokuhiro_ joined 15:44 kjs_ joined
hoelzro o/ #moarvm 17:02
17:38 tokuhiro_ joined 17:41 kjs_ joined 18:17 FROGGS joined 19:29 vendethiel joined
hoelzro jnthn: I tried merging in my memory leak fixes last night, but it segfaults with your recent change to flag_count. Could you clarify for me how flag_count on MVMArgProcContext and MVMCallsite should relate? 19:33
jnthn hoelzro: flag_count is only applicable if arg_flags is set 19:34
hoelzro: That is, only set in flattening contexts
hoelzro hmm; would that result in a valid situation where MVMArgProcContext.named_used would be NULL? 19:35
that's what's segfaulting, and the creation of named_used seems to depend on arg_flags and flag_count
jnthn Well, if there are no nameds, for example... 19:37
hoelzro jnthn: does a context lacking arg_flags imply that its callsite will also lack arg_flags? 19:39
19:39 tokuhiro_ joined
jnthn No 19:39
Callsties always have argflags 19:40
Well, expcet maybe the zero-arg site
hoelzro so assert(callsite->flag_count > 0) should always work?
19:40 domidumont joined
jnthn No 19:41
The zero-arg callsite has a 0 flag count
foo() # 0 args
hoelzro ah, that makes sense
jnthn: should the flag_count on a context and its callsite match? 19:44
I'm trying to figure out how contexts are getting created without named_used and segfaulting
jnthn No 19:46
They may match, but it's only by luck
hoelzro alright
thanks!
jnthn my @a = 1; foo(|@a) # a case where they match
The first has 1 flattening arg
The second has 1 arg
(callsite the flattening, the context the 1 arg)
hoelzro ah ha 19:47
dalek arVM: 5e283c5 | peschwa++ | src/core/interp.c:
Check if the next outer is null in bindlex.

Analogous to commit b370dd9. I don't think we hit this, but the semantics are equivalent and we could hit it when trying to bind further out than outers are actually available.		 20:03
arVM: 1001d53 | FROGGS++ | src/core/interp.c:
Merge pull request #300 from peschwa/master

Check if the next outer is null in bindlex.
21:41 tokuhiro_ joined 22:42 kjs_ joined 23:42 tokuhiro_ 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!