github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo i didn't manage to finish the blog post :( 00:35
MasterDuke timotimo: did you notice in Skarsnik's gumbo profile it's almost completely not jitted (but is almost completely speshed) 01:19
ugexe MasterDuke: i just did a profile of zef with the same result... 0.11% jitted and 98% speshed 02:05
MasterDuke ugexe: if you create a spesh log and grep it for 'bailed' what do you get? 02:17
i'm seeing some 'jit bailed completely' because of abs_n 02:29
which is called by `term:<now>`. so that seems problematic for anything calling now in any kind of hot code 02:30
ugexe gist.github.com/ugexe/c2726e7da6ba...d66b40b2f5 02:31
that is all the bail lines
MasterDuke huh. no 'jit bailed completely', that i don't understand... 02:38
ugexe i have some of those, they just werent grepped into that 02:39
MasterDuke ah, i think those are more important for figuring out jitting percentages 02:40
ugexe there is 30 of those 02:46
gist.github.com/ugexe/9e8861b2ef60...10cbaaa802 02:49
so without knowing anything about the jit... what makes return_s and return_i templates more difficult than the existing e.g. return_o ? 02:51
MasterDuke i'm seeing pretty much the same ones. but i think those pretty well known to be be jitted. maybe the 'param_*_o' ones should have been jitted?
a real quick glance makes me think return_s and return_i should be pretty straightforward to make templates for, would be just slightly simplified versions of the return_o template 02:53
i suspect they just aren't that all that common which is why nobody has done them yet 02:54
ugexe the only difference i immediately could find is _s and _i are :useshll
MasterDuke i have a spectest running right now for a different change and i'm going to bed soon, but if nobody else gets to it first i'll try and create templates for them tomorrow evening 02:58
.tell timotimo if you check the logs here colabti.org/irclogger/irclogger_lo...9-03-22#l5 you'll see some discussion i had with ugexe about weird profile/spesh log results. you might have some comment 02:59
yoleaux MasterDuke: I'll pass your message to timotimo.
ugexe i think i figured out how to do return_s (it takes a pointer like _o) but my attempt at return_i is segfaulting 03:09
MasterDuke you're using `(carg $0 int)`? 03:12
ugexe yeah
MasterDuke huh 03:13
ugexe hmm if i delete the spesh bits at the start it does not segfault 03:15
gist.github.com/ugexe/dcf05a184145...eea41df324
(note the spesh log stuff removed only from return_i) 03:16
MasterDuke maybe need to add _i and _s here github.com/MoarVM/MoarVM/blob/mast...ph.c#L3675 ? 03:20
ugexe well i dont know what im looking at (lol), but my first reaction is that `case MVM_OP_return_i: {` is different from the empty `case MVM_OP_return_s:` and `case MVM_OP_return_s:`, and that the code in the return_i case might be whats causing the segfault when jitted 03:27
ugexe or am i misparsing C and all those case statements run that block? 03:28
MasterDuke those empty cases all fall through to the block in _i 03:29
ugexe ok that makes more sense than what i was thinking 03:30
i added what i thought was right, but it still segfaults for return_i (and seemed fine for _s without this) so i'm not sure if its needed? `if (op == MVM_OP_return_o)` -> `if (op == MVM_OP_return_i || op == MVM_OP_return_o || op == MVM_OP_return_s) 03:36
`
MasterDuke hm. can you run it in gdb or lldb to get a backtrace? did you configure moar with debugging symbols? 03:39
ugexe perl6-lldb-m doesn't seem to work right on my system 03:45
gist.github.com/ugexe/1a9839c520f0...b6a8122b04
MasterDuke weird, i've never seen that before 03:47
ugexe looks like its the relocatable branch merge 03:49
MasterDuke i haven't tried gdb or lldb since that merge 03:52
fwiw, both work for me in kubuntu 18.10 03:55
ugexe im on osx
MasterDuke i gotta get to bed. i'd suggest asking brrt, timotimo, jnthn, or nine if you don't figure it out. good luck 04:02
ugexe i sent a pr with return_s to get my toes wet. i'll have to leave return_i to someone else, or until i'm in the mood to poke at a segfault
thanks MasterDuke
brrt good * #moarvm 11:17
.tell ugexe I'll have a look 11:33
yoleaux brrt: I'll pass your message to ugexe.
patrickb o/ 13:08
yoleaux 03:54Z <ugexe> patrickb: gist.github.com/ugexe/a88a63154eee...81390e6d5b
patrickb .tell ugexe: I'll have a look. 13:08
yoleaux patrickb: What kind of a name is "ugexe:"?!
patrickb .tell ugexe I'll have a look. 13:09
yoleaux patrickb: I'll pass your message to ugexe.
patrickb .tell ugexe I'll probably manage to finish the fix for msvc this evening.
yoleaux patrickb: I'll pass your message to ugexe.
ugexe brrt: the return_i template i tried segfaults on osx but not on debian 14:55
yoleaux 11:33Z <brrt> ugexe: I'll have a look
13:09Z <patrickb> ugexe: I'll have a look.
13:09Z <patrickb> ugexe: I'll probably manage to finish the fix for msvc this evening.
ugexe unfortunately i have can never get e.g. gdb working on osx to debug segfaults 14:56
lizmat ugexe: there appears to be an lldb ? 14:59
ugexe that doesn't work either 15:00
lizmat never had much success with that either :-( 15:01
ugexe i think they work if you use old kernels 15:02
ok i got it to segfault on linux as well, so i should be able to get some more info 15:09
gist.github.com/ugexe/33b5130b881e...f615ae295a This is the gdb output from the segfault when implementing return_i that includes callv (^func &MVM_spesh_log_return_type_from_jit 15:11
jnthn iirc, that only applies to object returns 15:26
Ah, or more to the point you'd need to pass NULL, not the value, perhaps 15:28
brrt` ugexe: that's... weird 16:46
oh, I understand 16:48
timotimo published that blog post: wakelift.de/2019/03/22/intermediat...snapshots/ 22:41
jnthn timotimo++ # nice work, nice post 23:08
timotimo yay, thanks 23:12