freenode/#clasp - IRC Chatlog
Search
14:20:26
Colleen
Bike: karlosz said 10 hours, 5 minutes ago: local call stuff is finally in. i decided to push it without the fastcc stuff because it seems like it doesn't make much of a difference but will try to actually figure how to make that work
14:46:50
Bike
i asked t his before, but do you know what could be happening that backtraces display the C++ified fnction names and no arguments?
15:33:58
docl
thanks yonkunas! I was using the outdated docker image from https://hub.docker.com/r/drmeister/cando/ before, this one looks a lot more recent. I'm interested in nanotech in general, kind of want something to show off to my friends at this point. the spiroligomer stuff looks really interesting.
15:52:09
drmeister
Since I'm on this weak MacBook Pro I've been working remotely a lot using an iMacPro (bigmac) that I have on my desk at home. I use the ThirdLaw VPN to access it using: http://172.235.11.1:8888/lab/workspaces/auto-e (for example) as the URL.
15:52:25
drmeister
It's working very well and very smoothly. I also do development by connecting in with slime. But I need to be careful to have the same source on this local machine as I have on bigmac.
15:52:48
drmeister
I usually have an ssh session opened into bigmac as well running emacs. I can connect into the swank server of the cando running the kernel using that and then I'm editing source on bigmac. It's a workable development environment.
16:10:54
drmeister
Ok - then (core:safe-backtrace) <<- a more raw backtrace that shows everything - not just what clasp thinks are lisp frames...
16:14:11
drmeister
Damn - I can't connect to the process with lldb because Apple has nerfed their operating system.
16:17:30
drmeister
Here is the relevant part of the backtrace generated using lldb and then symbolicating it with jitted symbols.
16:17:57
Bike
i also tried tracing interpolate-function, which is what does inlining, and it's not being called
16:22:25
drmeister
Ok, I'll generate the llvm-ir and look at it. It's not being generated at the moment.
16:24:29
karlosz
i forgot to mention, but the new changes now make it so we use sjlj for the lexical non local exits in Eclector, so there is no more unwinding for terminate-token in particular
16:27:18
Bike
i had to merge your changes with mine, so i suppose i could have screwed it up somehow, but it seemed pretty straightforward
16:27:37
karlosz
the l_... versions of the functions are just the "inner" functions that get called by the external entry point
16:27:54
karlosz
i was trying to make it so that the l_... versions of the function are fastcc but couldnt figure how
16:28:15
karlosz
as you can see a lot of the times both the l_ version and the non-l version exist of those exist in the backtrace
16:30:19
karlosz
because i marked the inner functions private i think that gives llvm liberty to automatically make the functions i was trying to make fastcc
16:32:10
Bike
karlosz, different functions in the same file should be in different bir modules, right? they're not local calls
16:33:21
drmeister
I was expecting a call chain line REPL-[regular-call]>AAA(ccc)-[tail-call]>AAA(fastcc)-[regular-call]>BBB(ccc)-[fast-call]>BBB(fastcc)...
16:35:13
drmeister
How can this even work? I thought this was impossible - a tail call to a varargs function???
16:35:35
Bike
ok well iirc llvm can ignore the tail annotation, so they wouldn't be actual tail calls
16:39:56
drmeister
Can you guys figure out what is going on? Is this not an abomination? %3 = tail call { i8*, i64 } (i8*, i64, i8*, i8*, i8*, i8*, ...) %entry-point-gep-gep(i8* %2, i64 1, i8* %0, i8* undef, i8* undef, i8* undef), !dbg !33
16:41:38
Bike
https://github.com/clasp-developers/clasp/commit/525bc12f9e5607ca9d2ea3d9a33ad80dc60568e4#diff-6a3dee58068bbd521a10f7eb383dea195b100bebe4256fbbacf681dcacd5a1ecR801-R810 or tail, even? what the heck
16:44:50
drmeister
You mean frame-pointer-elimination? We take trouble to NOT do frame-pointer-elimination because that damages the backtraces.
16:45:14
drmeister
Not like this though - we see the backtrace - it's not truncated (which is what fp elimination does).
16:46:14
Bike
i mean i thought sbcl mgiht do frame pointer elimination on things marked as tail call even if it doesn't do an actual tail call
16:47:19
karlosz
i just marked the inner function as "private" linkage, and the external entry points are still internal linkage
16:48:42
drmeister
karlosz: I've used internal or private linkage before - indeed - I make sure nothing is external linkage other than one function to initialize the module.
16:50:16
karlosz
even when i was making my local call change, i never saw fastcc show up when doing (disassemble ... :type :ir)
16:52:32
drmeister
I wouldn't trust disassemble - or rather - I would absolutely trust the .ll file you get from (cmp:compile-file-serial ...) if you turn on USE_HUMAN_READABLE_BITCODE in wscript.config
16:53:14
drmeister
The .ll file that you get from compile-file-serial contains absolutely everything that the compiler generates and that the runtime will do when it runs the code.
16:53:33
karlosz
in the ll file you can see there is still a distinction between tailcall fastcc and tail call
16:53:56
karlosz
interestingly enough the tailcall fastcc's are keeping the backtrace info but not plain tail calls
16:55:42
karlosz
not sure where in the BIR process did we start telling llvm its okay to always use tail calls
17:02:46
karlosz
i think the backtrace issue where the frames for tail calls are missing is indeed one of the issues with the debug info we were seeing but Bike should confirm
17:06:29
Bike
my comlpaint was frames looking like "_DDD^COOMON-LISP-USER^FN^^.11" with no arguments
17:07:42
drmeister
Ok, the no arguments is probably because you aren't setting up the argument save area and you aren't spilling the arguments into it.
17:08:10
drmeister
None of the functions have that big annoying block of argument spilling code in them. That's why there are no arguments.
17:09:01
drmeister
This needs to be called... https://github.com/clasp-developers/clasp/blob/bir/src/lisp/kernel/cmp/cmpintrinsics.lsp#L680
17:10:00
drmeister
I think the function names are weird because they aren't being demangled somewhere in the backtrace processing code for lisp frames.
17:10:22
karlosz
right, it should be eeasy to generalize the code that makes the 2 entry points into making multiple
17:10:29
drmeister
I think it uses that mangled name to come up with the name that it prints in the backtrace for lisp frames.
17:11:33
drmeister
Also, we will want to conditionally spill registers - so we can turn it off for high optimization levels. But I like seeing arguments in backtraces and I'll happily pay a bit of performance to get them.
17:12:15
drmeister
Ok, can you guys figure out what is going on from here and decide how we want things to work?
17:13:17
karlosz
Bike: given what drmeister said, i think you just need to add the call to maybe-spill-to-register-save-area in layout-xep-function like where it was in HIR
17:13:31
drmeister
I see: 1. Not spilling register arguments; 2. Frame names need to be demangled and the demangling code may not recognize some new mangling that is going on - find the demangling code and figure out what's up with it; 3. WTF is going on with fastcc and tail calls?
17:14:04
drmeister
3. (cont) and once we figure out what is going on with fastcc and tail calls - can we use it constructively?
17:14:39
karlosz
I think fastcc is being used correctly, will have to figure out whats going on with the plain tail calls and how to fix the backtrace
17:16:43
drmeister
Are the tail calls with the C calling conventions legal? Or is this some kind of bizarro undefined behavior?
17:21:14
Bike
it doesn't seem like a tail marker with the c convention is illegal so much as that it won't be optimized as a tail call
17:21:39
karlosz
it seems like it is a tail call in this case because we are losing the stack frame precisely when we have non fastcc call
17:24:32
Bike
and i don't think there's any new mangling. i mean, i can see how l_ would screw it up, but it's not unmangling the regular ol function names either
17:29:17
karlosz
yes i think the l_ functions are purely just from the main function entry point i added which is fine
17:33:55
Bike
i'll just make it always t and see what happens and then worry about policy communication
17:41:51
karlosz
so i was thinking about how to get rid of the continuation variable in unwind and i think this approach might be cleaner than what we have right now: 1. Define a new class LEXICAL which lexical-variable and catch both subclass. LEXICALs are things that can go into environments. Instead of closing over the continuation variable, we just close over the catch instruction directly instead.
17:42:09
karlosz
This has a few benefits: No strange non lisp object rtype needed for the continuation object
17:42:28
karlosz
No need to maintain the readvar stuff in unwind - it already has a slot for its catch
17:42:34
Bike
the rtype is just a reflection of what's actually happening on the lower level. it's not a tagged pointer
17:43:13
karlosz
Since the contvar is already mutable, we can simply identify it with the catch instruction anyway