github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 8 May 2018.
01:57 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
05:19 geekosaur joined 05:29 geekosaur joined 07:12 brrt joined
brrt good * 07:12
i have sad news... the 'jit-stack-walker' branch has run into what seems to be an insurmountable issue 07:13
gist.github.com/bdw/6d5b4ca6a7d2a3...74174cdad0 07:16
I'll spare you the staring
the first thing below rbp isn't the previous rsp, but (I think) the stored $rbx 07:19
hmm 07:21
i'm going to think some more here. there may be a solution
nine (rubber duck debugging)++
yoleaux 8 May 2018 12:04Z <lizmat> nine: some S01-perl5-integration tests have become rather flappy (with segfaults underneath :-( )
brrt ohai nine 07:22
there was something rather simpler I was going to be doing as well :-)
nine: can you run jit-bisect.pl --spesh on them?
I saw you made 'save rv' into it's own separate node. 07:23
nine .tell lizmat There's also github.com/niner/Inline-Perl5/issues/106 but without OS X I don't know how I could debug this :/ 07:24
yoleaux nine: I'll pass your message to lizmat.
brrt it can be made into a 'return value handling mode, I think. This has the advantage of being 'atomic' with the call
i.e.
JIT can't insert crap inbetween
nine Things only fail on OS X, so I can't make any progress on this :/ 07:25
lizmat nine: ah, I hadn't realized that 07:50
yoleaux 07:24Z <nine> lizmat: There's also github.com/niner/Inline-Perl5/issues/106 but without OS X I don't know how I could debug this :/
jnthn morning o/ 09:17
lizmat o/ 09:27
brrt: jit-stack-walker branch builds cleanly for me and spectest is also clean (except for known MacOS issues) 09:56
samcv do we have a define we use for if we detect 64 bit cpu or no?
lizmat brrt: same for jit-moar-ops branch 10:12
I will now merge that branch, unless someone stops me in the next 5 mins
Geth MoarVM: samcv++ created pull request #856:
Implement memmem_two_uint32, up to 45% faster index of short 32bitstr		 10:22
MoarVM: 995bd994f2 | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Enable ctxlexpad and hllizefor (with constant argument)

If we know the constant name for the hllizefor (which I imagine to be the case, most of the time) then it is basically the same thing as hllize.		 10:23
MoarVM: cc75d70ce3 | (Bart Wiegmans)++ | src/jit/graph.c
[JIT] Enable threadlockcount

Simple function
MoarVM: 372d0582ab | (Bart Wiegmans)++ | 2 files
[JIT] Implement capturenamedshash

Not so simple, but simple enough, especially with a few macros
lizmat brrt: this appears to bring a little improvement, but it could also be noise 10:38
.tell brrt two new BAILs for test-t: lexprimspec and captureexistsnamed 10:39
yoleaux lizmat: I'll pass your message to brrt.
lizmat .tell brrt which, incidentally, are the same two for 'say ^Inf .hyper.grep(*.is-prime).skip(9999).head', so I guess test-t itself is now completely JITted 10:43
yoleaux lizmat: I'll pass your message to brrt.
10:47 brrt joined
brrt \\o 10:49
yoleaux 10:39Z <lizmat> brrt: two new BAILs for test-t: lexprimspec and captureexistsnamed
10:43Z <lizmat> brrt: which, incidentally, are the same two for 'say ^Inf .hyper.grep(*.is-prime).skip(9999).head', so I guess test-t itself is now completely JITted
brrt lizmat: thanks!
.tell samcv I think we do, let me check
yoleaux brrt: I'll pass your message to samcv.
samcv brrt: ok thanks
yoleaux 10:49Z <brrt> samcv: I think we do, let me check
brrt we have MVM_PTR_SIZE 10:50
for me, that is configured as '8'
you also have MVM_JIT_ARCH, but that is more specific to the JIT; more importantly, MVM_JIT_ARCH_X64 is not a defined constant 10:51
samcv ok 10:52
brrt all that by design :-)
anyway
there's also ways to get the list of defined constants from the c preprocessor
cpp -dM < /dev/null 10:53
so what you also have is __LP64__ for 64 bit platforms 10:54
10:55 AlexDaniel joined
brrt blog.kowalczyk.info/article/j/guid...-etc..html 10:57
(If things were totally up to me, *and* I had infinite time, we'd probably just compile a tiny C program with a bunch of #ifdef tests, and replace all of Configure.pl with that) 10:58
11:05 AlexDani` joined
brrt so the thing is, the reason why the jit stack walker is broken on win64 isn't really restricted to windows 11:17
nwc10 it hates all platforms equally? 11:19
11:25 Kaiepi joined 11:49 domidumont joined 11:57 domidumont joined
brrt :-) 11:57
-fno-omit-frame-pointer only enforces that a frame pointer *is* stored. it doesn't mean that the thing below rbp always is the previous rbp
well, that, or gcc has a rather scary bug 11:58
lizmat rbp?
brrt Base Pointer, r prefix stands for 'extRa' extended or something (64 bit versions) 12:02
lizmat ah, ok :-) 12:03
brrt so. If I make this a compile-time switch, then at least we can see if this benefits anyone 12:04
but i still have to maintain the invariant that we store the current position for the platforms for which it doesn't work, and there *will* be some day that it breaks for platforms that it works on now 12:06
unless i can either a): improve the implementation so that it works (e.g. by searching the stack for a suitable rbp) or b): beat windows compilers so they DWIM 12:07
i mean, noone selects -fno-omit-frame-pointer *explicitly* so that stack walking is broken still
lizmat so maybe the idea is not such a good idea after all ? 12:12
brrt :-( 12:16
yeah
i still want to get rid of the current-position-updates though
one way i know of just ends with making c calls a bit slower. i'm not terribly optimistic about that though 12:17
lizmat yeah, to me this issue has a refcounting feel about it 12:18
nine brrt: can the problem you're trying to solve be phrased as "to which position in the MoarVM bytecode does a certain position in the x86 bytecode correspond"? 12:19
jnthn That's the easy part, I think. The hard part is finding where the JITted code is on the stack 12:20
nine I'm not sure I understand the second part? 12:22
Well, if I do understand correctly, that does sound kinda hard... 12:23
jnthn JITted code calls C function. C function calls another C function. That occasionally throws an exception. How do we find the PC of the JITted stack frame which is n down.
As I understand it, brrt was trying to use compiler flags to make it possible to reliably do that. 12:24
brrt that is precisely correct
the first part is adequately solved by looking at the relative position compared to a set of labels 12:25
labels have 0 runtime cost
jnthn: and I almost but not quite succeeded
:-(
the current implementation is 'just store our current position all the time'. that is inefficient 12:26
and limiting, because it must be enforced strictly
nine Could we get to a point where we'd only have to store it occasionally? Like only when we call a C function but not at the other points where we have to do it now? 12:29
I.e. solve 80 % of the problem
brrt we call C functions very often :-)
iirc, parrot implemented exceptions by a pushhandler, pophandler combo 12:30
lizmat and the advantages / disadvantages are ?
brrt you pay for exceptions when you're not using them 12:31
currently, if you don't use them, they're free
jnthn Right. Basically an exeption handler that's never triggered has no direct runtime cost.
brrt: And "not quite succeeded" is because even with the compiler flag, the stack layout still isn't quite predictable enough? 12:34
nine Well at least it seems to be possible: msdn.microsoft.com/en-us/library/w...s.85).aspx 12:39
Though as that is part of some debug library, it may depend on debug symbols 12:40
timotimo we do have a whole lot of handlers in our bytecode 12:41
nine Though according to blogs.msdn.microsoft.com/vcblog/20...k-walking/ stack walking doesn't need debug information 12:44
On GNU systems there's int backtrace(void **buffer, int size); It's source code may at least give good hints. Though it's docs also mentions: Omission of the frame pointers (as implied by any of gcc(1)'s nonzero optimization levels) may cause these assumptions to be violated. 12:49
brrt yeah, i found that as well
not the dia-based-stack-walking, though
i think the gnu backtrace one used a special ELF header 12:51
13:03 FROGGS joined 13:10 gtodd left 16:10 brrt joined
brrt ok, so i have a new, evil plan 16:25
if we can't *walk* the stack to find the return address 16:31
surely we can still scan it?
i mean, how may 8 byte pointers within the stack frame can there be? 16:34
... i'm not totally fond of the solution, because it is entirely heuristc, though
jnthn Yeah, I was pondering if we could do something heuristic, but it feels a bit fragile 16:42
brrt maybe i can figure out how others do this 16:44
samcv so if i catch what's going on. we walk the stack to find MVM bytecode we need to switch to? 16:47
and gcc/msvc don't always set rbp register to the location of the current stack frame though they used to? 16:49
jnthn We don't walk the (C) stack at all today. But the goal is to walk it to discover the current PC of code generated by the JIT, which we can then easily map into a bytecode location
samcv pc?
brrt process counter 16:51
brrt afk
jnthn Program Counter (the address of the code the CPU was executing0
*)
samcv ah. so it seems compilers (msvc) seems to not set it? since it isn't always required? 16:52
though from the small amount of assembly i know, it would *usually* maintain the correct position?
jnthn Seems there's options that control whether it is set 17:00
Well, stored on the stack
brrt: I wonder if we could do it the other way around. Since we always enter the JITted output via a common place in the interpreter, and we emit the calling code, is there no way we can find the return address from going the other direction? 17:01
brrt: That is, knowing the stack position before we enter the JITted code? 17:02
Since the JIT output is 1 function, so one frame
dinner &
19:20 robertle joined
lizmat brrt: did you see github.com/rakudo/rakudo/issues/1810 ? 19:59
Geth MoarVM: cbf26fa793 | (Elizabeth Mattijsen)++ | src/jit/graph.c
Disable ctxlexpad inlining

As an attempt to fix Rakudo #1810		 20:02
jnthn That doesn't disable inlining, it disables JIT compilation of it, no? 20:06
lizmat ah... hmmm... well, that was the difference with before, afaik
jnthn: are you saying what I'm doing won't make a difference, or that the commit message is wonky ? 20:07
jnthn lizmat: Just the commit message :) 20:21
lizmat ok, *phew* :-)
MasterDuke timotimo: just saw a new warning when compiling, `src/profiler/telemeh.c:202:5: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]` 20:49
timotimo ah, in that case i should perhaps just use strcpy? 20:51
since the n doesn't give me any different behaviour
MasterDuke heh, i have no idea, but that sounds plausible 20:53
21:04 AlexDaniel joined
Geth MoarVM/pluggable-spesh: bf1edc9055 | (Jonathan Worthington)++ | 6 files
Add new guard spesh ops

To be used when implementing the spesh plugin guards.		 22:43
22:47 Kaiepi joined
Geth MoarVM/pluggable-spesh: f6341089a4 | (Jonathan Worthington)++ | src/spesh/plugin.c
Emit exact object match guard for spesh plugins

Means that we can now deopt when we fail to match the expected literal object.		 22:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!