Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:00 reportable6 left 00:02 reportable6 joined 01:02 linkable6 left, evalable6 left 01:03 evalable6 joined 01:04 linkable6 joined 03:42 evalable6 left, linkable6 left 03:43 linkable6 joined 03:45 evalable6 joined 04:54 discord-raku-bot left, discord-raku-bot joined 05:54 discord-raku-bot left 05:55 discord-raku-bot joined 06:00 reportable6 left 06:02 reportable6 joined 06:45 harrow` left 06:54 discord-raku-bot left 06:55 discord-raku-bot joined 07:03 harrow joined 07:55 discord-raku-bot left, discord-raku-bot joined 08:55 discord-raku-bot left, discord-raku-bot joined 09:05 sena_kun joined 09:55 discord-raku-bot left, discord-raku-bot joined 10:55 discord-raku-bot left, discord-raku-bot joined 11:56 timo joined
timo who wants to investigate if adding integers alternatingly with lea and add assembly instructions can make stuff faster? since they use different stages of the pipeline to do their work. or maybe only using lea is better as long as we don't need any flags like overflow or is-zero or whatever 11:57
12:00 reportable6 left, reportable6 joined
timo maybe also check if i'm full of crap with this assumption 12:05
lizmat isn't that something that a compiler would need to know / do ? 12:06
timo if we could use lea to do X + Y * c + d with c and d being constants, that would perhaps be cool? not sure if we ever get that
yeah those changes would go in the jit
is this something the tiler could automatically do when we give it an appropriate tile? 12:08
i still don't exactly grasp how that bit of the thing works actually
12:55 discord-raku-bot left 12:56 discord-raku-bot joined 13:55 discord-raku-bot left 13:56 discord-raku-bot joined 14:56 linkable6 left, evalable6 left, linkable6 joined 14:57 evalable6 joined
japhb gcc/clang do indeed do LEA optimization automatically. But of course, if we want to have the JIT do that, we'd have to do it ourselves as you say. 15:51
lizmat looks like some spesh issue: github.com/rakudo/rakudo/issues/5160 17:36
18:00 reportable6 left 18:02 reportable6 joined
timo the 40% one from the op and liz's 100% crasher with ^7 both don't crash on my machine, but i'm some versions back 18:34
Rakudo™ v2022.07-86-g64f552f32. Built on MoarVM version 2022.07-20-g757524899.
right, that's before the version that's mentioned as breaking in that ticket 18:45
somehow i thought we did the switch to main like years ago lol
i do actually get a crash in the jit, but it looks like there could be some memory corruption going on 19:07
trying to catch it in rakudo-valgrind-m right now 19:08
so jitting crashes while trying to compile the getattrref_s call in the -e code 19:33
that seems to be wrongly using MVMint16 for a lit_str_idx in jit/graph.c where it should be an MVMuint32, so that's another patch that needs to go in 19:46
19:54 discord-raku-bot left, discord-raku-bot joined 20:04 vrurg joined, vrurg_ left
timo oh yikes, spesh is infinite-recursing and that's what segs the fault? 20:13
lizmat: does the backtrace from your crash with lldb or whatever also look a little too long? 20:15
lizmat I didn't look at that level 20:16
but infinite recursion... could be
21:27 dogbert17 joined
dogbert17 .tell timo I have updated the issue with some gdb output that might possibly be of interest 21:28
tellable6 dogbert17, I'll pass your message to timo
dogbert17 .tell timo I believe that your Perl6-Github-Linkify script is a bit broken since the master -> main switch 21:29
tellable6 dogbert17, I'll pass your message to timo
22:41 sena_kun left 22:56 epony left 22:58 discord-raku-bot left, discord-raku-bot joined