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
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
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
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
brrt good * 21:30
lizmat++ weekly
timotimo lizmat++ # weekly 21:47
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
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 :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!