01:48 evalable6 joined 02:58 ilbot3 joined 06:40 domidumont joined 07:26 domidumont joined 07:32 robertle joined 07:40 brrt joined
brrt good . 07:40
yoleaux 3 Mar 2018 12:50Z <MasterDuke> brrt: i did actually try re-writing it to `(template: ishash (if (all (nz $1) (eq (^getf (^repr $1) MVMREPROps ID) (const (&QUOTE MVM_REPR_ID_MVMHash) int_sz))) (const 1 int_sz) (const 0 int_sz)))`, but it still give an MVM_oops in the same spot
3 Mar 2018 17:03Z <nine> brrt: in general, higher level semantics (like a STORE_WRITE_BARRIER) make it easier for a compiler to apply optimizations, so I'd favor that.
brrt .tell MasterDuke yeah I'm seeing it. I really wonder how you're getting a CAST_LOAD_ADDR from that 07:41
yoleaux brrt: I'll pass your message to MasterDuke.
brrt nine: I've swung back on that, mostly because a STORE_WRITE_BARRIER operator node needs an associated tile
and that associated tile needs the same kind of handling that CALL/CALLV does, except 'magical' 07:42
which is a pain, currently
I kind of want to generalize that but it's not easy
on the other hand, having 'named partial templates' isn't exactly hard to do, and it is a nice generalization from the macro concept, I think 07:43
07:54 AlexDaniel joined
samcv jnthn: it seems that MVM_string_decode is not used once in our codebase except in io/dirops.c 08:00
though i don't think it can be triggered unless you try and decode a directory as windows-1252, there is a bug where \r\n won't decode into a single grapheme. at least from reading the code it doesn't do anything with that 08:01
ok well it actually may working looking at it closer. but regardless it isn't tested 08:05
anyway i will see if i can unify some of the code there 08:09
08:13 brrt joined 08:17 zakharyas joined 08:19 brrt joined 08:22 zakharyas joined 08:27 domidumont joined
samcv ah oops i guess i missed where it was being called. it's getting late 08:36
nwc10 "insufficiently morning"? 08:38
They respawn daily
brrt good hi :-) 08:43
nwc10 there's this strange cross symbol appeared at the start of temperatures - does anyone know what it means? :-) 08:44
(this joke is somewhat Euro-centric) 08:45
and might not be funny :-)
brrt a symbol like '+' ? 08:48
nwc10 yes, that's the one. 08:50
most unusual
09:17 AlexDani` joined 09:54 Geth joined 10:16 quotable6 joined, nativecallable6 joined, bisectable6 joined, greppable6 joined, evalable6 joined, benchable6 joined, reportable6 joined 11:13 yoleaux joined 11:45 shareable6 joined 11:59 brrt joined 12:23 brrt joined 12:33 buggable joined 13:46 Ven`` joined, zakharyas joined 13:58 domidumont joined 14:04 AlexDaniel joined 14:18 zakharyas joined 14:37 zakharyas joined 14:48 domidumont joined 14:55 zakharyas joined 14:57 TimToady joined 15:01 greppable6 joined 15:32 bisectable6 joined 15:33 zakharyas joined 15:55 reportable6 joined 15:57 reportable6 joined, quotable6 joined 15:59 reportable6 joined 16:05 nativecallable6 joined 16:08 brrt joined 16:13 releasable6 joined 16:40 Kaiepi joined 17:06 bisectable6 joined 17:23 Kaiepi joined 17:31 domidumont joined 18:15 zakharyas joined 18:45 Ven`` joined 19:05 Ven`` joined 19:16 Kaiepi joined 19:17 Ven`` joined, reportable6 joined 19:30 zakharyas joined 19:34 zakharyas joined 19:57 Ven`` joined 20:04 zakharyas joined 20:17 Ven`` joined, brrt joined
brrt ohai #moarvm 20:19
interestingly, changing the order of the store and the write barrier breaks NQP compilation, even though it really shouldn't 20:20
nwc10 does valgrind have anything to say about this? 20:24
brrt good question 20:30
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/03/05/...atic-perl/ 20:36
20:37 Ven`` joined 20:42 Ven`` joined 21:01 Ven`` joined 21:11 Kaiepi joined 21:21 Ven`` joined 21:24 brrt joined 21:27 evalable6 joined
brrt good * 21:30
lizmat++ weekly
timotimo lizmat++ # weekly 21:47
21:49 robertle joined
brrt the bug with changing the order of the write barrier manifests in a gigantic jit file 22:03
timotimo do we perhaps want an env var JIT_MAX_SIZE :) 22:05
so perhaps it takes a bit longer to trigger the bug, but then at least the jit code will not be huge 22:06
brrt hehe 22:07
let a million env vars bloom
I see a set that's eliminated o.O 22:17
timotimo so the set operation doesn't exist any more but it's in the jit output?
brrt (i was also wondering if we could, maybe, compile 'happy paths' through the frame, if we can't compile it all; then I figured that would be reinvention of tracing) 22:18
no, there should be a 'set', but it was eliminated entirely by the expression compiler
timotimo ah 22:19
22:24 releasable6 joined
brrt we're having a sp_p6ogetvt_o of a VMNull object. curious 22:32
oh, and another case of double restoring 22:33
i'm surprised by how much inefficiency is generated by the spilling of the allocator 22:45
and surprised how correctly it all works
(except for where it's broken, of course)
xb
timotimo is it much worse than the lego jit?
brrt it's different worse 22:46
timotimo interesting
can you elaborate a little bit?
brrt well, the lego jit just endlessly, mindlessly loads the same things to and fro memory
timotimo right
brrt the expr jit can end up spilling, then restoring just after
that's a case of a known optimization that i haven't applied yet 22:47
see you tomorrow 22:48
timotimo OK :)
23:11 Ven`` 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!