timotimo bindlex lex(idx=7,outers=0,items), r8(8) 00:16
getlex r12(7), lex(idx=7,outers=0,items)
i don't even >_>
i thought we had something in place that inserts logs to see if things have changed since they got bound or something like that? 00:26
and we're supposed to improve handling of lexicals somehow?
doesn't seem so 00:27
the getlex_known will only fire for getlexstatic and getlexperinvtype (if spesh'd on invocant) 00:29
so that won't do anything here
00:47 vendethiel joined
timotimo jnthn: do you think i can add something to the profiler such that we'd see native subs appear in the results, too? 01:32
i'm not actually sure whether or not the code that does the native call setup and dispatch will get hit by the profiler code gen ... but now that i actually think about it, i see no reason why not
01:39 vendethiel joined
timotimo this isn't really hot code, but an acceptable example for a failure to eliminate a sink check: gist.github.com/timo/3d56aa47f53e43e7a500 01:54
^- notice especially how the predecessor list of bb 3 contains bb 3 itself and if that wasn't the case, we should've probably been able to remove the sink check 01:55
(this is based on a local patch that changes a single line: it turns the $!handled attribute of Failure to be int rather than Any - gets us rid of a getattr + vivification and assign and should have gotten us to an implementation of method defined that doesn't have a sink check at all ...) 01:56
02:04 vendethiel joined 02:59 vendethiel joined 03:32 vendethiel joined 05:06 sivoais joined 06:35 FROGGS joined 06:51 zakharyas joined 07:22 brrt joined
brrt *ahem* back 07:23
FROGGS hi brrt 07:29
brrt ohai!
FROGGS I did not understand what you said to me about dynasm
brrt long time ago you added a patch to choose a system dynasm for building moarvm 07:30
i myself have once added the feature to add a system lua for using dynasm
neither features have a purpose
minilua which we ship is good enough for compiling dynasm, which is the only thing we ever do with it 07:31
FROGGS ahh, that --has-dynasm probably happened when working with daxim++ on opensuse packages
brrt dynasm should be our own because we've patched it :-)
FROGGS I see
brrt and the --lua feature works poorly together with the 'ensure minilua is compiled' rule 07:32
so... they have to go 07:34
(i noticed this all because i got a SEGV in dynasm. it turned out to be from not recompiling the .dasc files after changing dynasm) 07:35
for the record, we don't ship the minilua tool, or the dynasm 07:40
they're purely build-time dependencies
FROGGS then we should get rid of the said options 07:41
brrt patch coming up :-) 07:43
FROGGS brrt++
dalek arVM/even-moar-jit: ff95f73 | brrt++ | / (2 files):
Building .dasc files depends on dynasm version

Because I've patched dynasm to support extended register addressing, c files generated with an old version of dynasm are not compatible with the header of the new version. This is fix by adding a dependency from dynasm-generated c file to the dynasm scripts, and from the corresponding object file to the dynasm headers.
At the same time, I've removed the --lua and --has-dynasm options from the configuration. The --lua option doesn't work well with the minilua-building rule, and the --has-dynasm option isn't very useful because our dynasm is now patched (and thus nonstandard). 4a6511f | brrt++ | / (4 files): Dump tree to inspect it.
This uncovered so many bugs.		 07:55
brrt hmmm 08:29
i have another question on which i'd like some advice
i have implemented a simple visitor for the JIT tree 08:30
i'm wondering if a): i want to have the visitor function control ascend/descend operations
and i'm wondering b): if i want to resolve multiple-node-entries during walks or in the visitor 08:31
two sides of the same coin, really
a code generator that is being 'walked' over the tree can of course keep it's own bookkeeping on whether we've seen certain nodes before 08:32
08:32 vendethiel joined
brrt if it can control the decision to ascend/descend, that means it can limit 'double walks' over the same tree 08:33
(i'm indeed not really talking about trees anymore)
on the other hand, are double walks so expensive that we should care? i'm skeptic 08:34
does mean we may have superlinear walking costs in a bad case; e.g. suppose the first n/2 nodes are used by the second n/2 nodes; we'd have O(n/2*n/2) = O(n^2) walking cost 08:35
kind of want to avoid that?
of course, why not do both 08:52
bugs bugs bugs 09:07
FROGGS O.o
brrt code is always so much better when it's never run 09:13
FROGGS :D
FROGGS .oO( Never touch a sleeping system... )
brrt my greatest scare so far was yesterday evening when all of the sudden perl6 crashed in the dasm_put function 09:15
that happened to be the 'dasc files isn't recompiled when dynasm scripts change' issue 09:16
(btw, dnf really is dramatically faster than yum) 09:18
note to self 09:22
when iterating over a linked list, be sure to transition to the next pointer
FROGGS :P 09:27
brrt hmmm 09:38
something up with the roots 09:39
y u no correct
(because you didn't copy them) 09:51
damnit, why do we get latin capital letter l in the output :-( 10:30
FROGGS why not?
brrt well 10:35
its an odd name for an opcode
FROGGS true 10:41
bbiab 10:42
brrt ugh, many difficult 11:08
11:11 FROGGS joined
brrt (of course it's difficult if you make mistakes. you dumbass) 11:36
FROGGS *g* 11:37
don't make mistakes then, it is pretty simple :o) 11:38
brrt the cool thing is, *it really works*
(holy redundant set, batman) 12:05
dalek arVM/even-moar-jit: 009d9e5 | brrt++ | src/jit/expr (3 files):
Minor improvements in tree generation

Don't store right after a load; skip no_op, phi nodes		 12:06
brrt i... think i need some kind of macro facility in the tree-expression-compiler script 12:07
otherwise this will get unwieldy very fast
oh, there's an error in there, too
dalek arVM/even-moar-jit: 58e9936 | brrt++ | src/jit/expr (2 files):
Minor fix of exprlist
 12:10
brrt ooh, more core dumps 12:11
hmm, never mind :-) 12:13
timotimo oh, things are moving forward? :D 12:17
can you show off some example dumps of the jit tree? :) 12:18
brrt yes 12:20
it's the simplest thing possible, but here it is 12:21
gist.github.com/bdw/80b52a7b7aaf967c2e03
timotimo does that come from a hand-crafted MAST tree?
like when you first built the very first JIT? 12:22
brrt no, just from the nqp source 12:24
it's just an empty set 12:25
(instruction)
timotimo oh lord, my favourite instruction :)
brrt the cage cleaning i was refering to implies removing the JitGraphBuilder 12:29
no reason why the graph couldn't be the live structure
jnthn Afternoon, #moarvm 12:30
brrt \o jnthn
still in kiev?
jnthn aye
hiding in air-conditioned apartment
12:31 rurban joined
brrt :-) 12:31
FROGGS hi jnthn 12:32
jnthn o/ FROGGS
FROGGS I've seen some shaped array commits have landed?
ohh, and you've blogged...
need to read that soonish
jnthn Where on earth did checked_free_null come from 12:33
C's free function is happy enough to get a NULL pointer
12:34 brrt joined
brrt JimmyZ made that patch. it replaced a free with a real null check, so if that was wrong it was wrong before :-) 12:34
bbl
jnthn Yes, I meant that if (foo) free(foo); is equivalent to free(foo);
'cus free already checked 12:35
*checks
timotimo ohai jnthn 12:36
JimmyZ really? so we don't need MVM_checked_free_null at all? 12:39
just MVM_free_null 12:40
jnthn Um, just MVM_free(foo); as far as I'm concerned 12:41
In the REPRs anyway
There's very few places where correctness requires you to actually NULL it 12:42
Some people might once have said it aids debugging
But with tools like valgrind and ASAN it actually hurts debugging to NULL freed pointers.
(If you never expect to look at them again) 12:43
JimmyZ ok, so we can change many MVM_checked_free_null to MVM_free ? 12:44
jnthn I'd say so 12:45
JimmyZ ok , I will do it. and remove MVM_checked_free_null(which is about 2 years old) 12:46
jnthn Righty, back to multi-dim stuff... 12:59
nwc10 jnthn: "afternoon"? - the coffee in this apartment isn't quite as good as the aircon? 13:00
jnthn nwc10: Well, also attempted some tourism and found some lunch. 13:02
It's just too hot outside to feel like doing much, alas... 13:03
nwc10 holiday suffers, MoarVM wins? 13:04
jnthn Maybe
Though last couple of days, and somewhat today, the allergy stuff gunked my ears up again some I've been feeling dizzy, which is crappy for doing anythhing... 13:05
timotimo that sucks :( 13:15
dalek arVM: cba9b92 | jnthn++ | src/6model/reprs/MultiDimArray.c:
Implement cloning multi-dim arrays.
 13:20
arVM: 53468a9 | jnthn++ | src/ (3 files):
Fill out remaining multi-dim array ops.
 13:48
jnthn Seems there's just the serialization bits left. 13:50
Then I've gotta move on up to the Perl 6 level bits... 13:52
14:15 dalek joined
dalek arVM: 647df11 | jnthn++ | src/6model/reprs/MultiDimArray.c:
Implement serialize/deserialize of MultiDimArray.
 14:27
jnthn Yays. 14:31
FROGGS \o/ 14:41
jnthn Decided to switch to RTs until dinner. :)
timotimo jnthn: +/- on teaching the profiler about nativecallinvoke? 14:42
jnthn Hope to work on the Perl 6 bits of multi-dim array stuff in the coming days
timotimo: What can we teach it? :)
I mean, +1 if you've got some concrete idea that gives us useful info ;)
timotimo AFAIK it doesn't measure time spent inside native routines at all
jnthn Ah, not as spearate routines,now 14:43
*no
timotimo and native routines don't show up in the profiler at all, right?
jnthn Aye
timotimo i mean, they don't have their own item with entries/exclusive/inclusive time etc
jnthn yeah, there's room for improvement and I can see it'd be nice to have :)
Correct, we don't do anything special with them yet
timotimo i'll have a look at how it'd be done and maybe implement it :) 14:44
jnthn My first idea would be to fake a call node in the profiler for it 14:45
call graph node, that is
timotimo that's what i think, too. i'd need something clever for the ->sf, though 14:46
i mean, i could potentially generate a fake staticframe for every native function we encounter
jnthn Oh, I'd NULL that
And maybe have a MVMString *native_name or char *native_name, whichever is most readily to hand 14:47
timotimo mhm
jnthn I suspect faking up a static frame will get fragile 14:48
timotimo the MVMNativeCallBody doesn't actually store the name of the target any more, just the entry point
i suspect so, too
jnthn Hm... 14:49
You could I guess keep the name around
timotimo well, we also have the name in the frame where we do the call in order to set things up 15:02
17:02 FROGGS joined 17:25 zakharyas joined 18:00 brrt joined
brrt \o 18:03
folks.. does it make any sense for me to make a macro facility in the expression tree compiler program? 18:04
why? because we have tons of repeated expressions 18:05
FROGGS I can't answer any of your questions :o( 18:08
I'd like to, but I can't
brrt hmm 18:16
hmmmmhmmm 18:17
dalek arVM/even-moar-jit: c470b65 | brrt++ | / (2 files):
Very minor fix (but a SEGV nevertheless)

An MVMOpInfo.opcode is unsigned short (MVMuint16); this caused some problems with an extension opcode which was interpreted negative.		 18:18
brrt my point is, in dynasm i've written tons of little helper macro's to e.g. get strings from the compunit 18:19
i find that s-exps get rather unwieldy after a point, especially in the level of detail i have to manage
and immensely error-prone 18:20
and.. i just think it'd be a lot less error prone to use fragments that are known to be good 18:23
macros
maybe there is something you can help me with 18:24
what sigil to give to my macro's
i'm thinking either * or ^
i like ^, 'on an upper level'
(i've already constricted $ for parameters and & for c-level macro invocations (and sizeof and offsetof) 18:28
% and @ would give the wrong idea, # is already for comments 18:29
also > would be possible
hell, lots of characters in ascii 18:34
brrt afk 18:35
FROGGS ohh, we are inventing a new language here? 18:37
19:03 colomon joined 19:39 Peter_R joined 19:49 ggoebel joined 19:56 brrt joined
brrt actually, somewhat like it; i have written a tree template preprocessor 19:57
it's really a (very tiny) compiler
these templates end up to form the expression trees 20:00
the thing is, now i have the problem of writing lots and lots of those tree templates 20:01
many of those are quite complex
they're written in s-exp, so you can probably understand that they become unwieldy 20:02
20:52 synbot6 joined 22:54 TEttinger 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!