freenode/#clasp - IRC Chatlog
Search
20:12:49
drmeister
Bike: THis thing about every function having two frames on the stack - can you explain that again?
20:18:11
Bike
one is the XEP and one is the main function. the XEP has the generic calling convention - closure, nargs, arg0 etc. it just immediately calls the main function, which has the actual function code.
20:18:51
Bike
i think the main function is marked fastcc, as part of an effort to allow tail calls. that might screw up the frame pointers
20:24:24
drmeister
Think about it. We have completely lost backtraces with this being the way it is.
20:24:54
Bike
if you just remove the two lines that set-calling-conv it'll probably go back to using the usual convention
20:25:21
Bike
backtraces still work for me, though, i don't really understand what you've changed that makes fastcc suck more
20:39:39
drmeister
Switching off fastcc does not fix the problem. What I think is the main function still lacks a frame pointer
20:47:38
drmeister
Where would the "FOO-AAA^COMMON-LISP-USER^FN^^" aka l_FOO-AAA^COMMON-LISP-USER^FN^^ be generated?
20:49:06
drmeister
It's where the code for that function is generated. It's the main function - so I think it's layout-main-function*?
21:05:48
drmeister
In terms of the function signatures I don't see any reason why the main-function should behave differently wrt frame pointer compared to the xep-function.
21:06:18
drmeister
define private { i8*, i64 } @"FOO-AAA^COMMON-LISP-USER^FN^^"(i8* %0) #2 personality i32 (...)* @__gxx_personality_v0 !dbg !84 {
21:06:42
drmeister
define internal { i8*, i64 } @"FOO-AAA^COMMON-LISP-USER^FN^^.6"(i8* %0, i64 %1, i8* %2, i8* %3, i8* %4, i8* %5, ...) #2 personality i32 (...)* @__gxx_personality_v0 !dbg !88 {
21:07:10
drmeister
attributes #2 = { uwtable "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" }
21:08:27
drmeister
They have different signature and the xep-function is internal and the main-function is private.
21:12:41
drmeister
I suspect that llvm is doing some optimization that we need to turn off if we want backtraces.
21:19:35
drmeister
https://github.com/clasp-developers/clasp/blob/imagesaveload/src/lisp/kernel/cleavir/translate.lisp#L67
21:20:35
drmeister
https://github.com/clasp-developers/clasp/blob/imagesaveload/src/lisp/kernel/cmp/cmpir.lsp#L861
21:20:51
drmeister
DONT USE "private" linkage - I encountered some pretty subtle bugs with exception handling (I think) when I did that.
21:32:52
drmeister
I changed the linkage to internal and something else changed - the prefix "l" is gone.
22:16:35
drmeister
I checked this out on the master branch of clasp - it DOES maintain a frame pointer for the main function.
22:39:03
drmeister
I run llc on a .ll file generated using imagesaveload/llvm12 and there is NO frame pointer
22:39:20
drmeister
I run llc12 on the .ll file generated using master/llvm9 and there is NO frame pointer.
23:49:08
attila_lendvai
hi! long time since i was around, but i remembered my ventures into clasp land... i'm having a lot of fun in the land of bootstrapping with this tiny self-hosting lisp: https://github.com/attila-lendvai/maru
23:50:12
attila_lendvai
drmeister, if you have weird bootstrapping issues, then i may have unique perspectives
23:51:16
attila_lendvai
Bike, i've worked a lot on it recently. the codebase is substantially more approachable now, has some tests, and the bootstrapping part is uncomparably better.
23:52:51
drmeister
Bike: I can see the Prologue/Epilogue Insertion & Frame finalization pass in llvm9 inserting frame pointer code and in llvm12 it does not.
23:53:19
attila_lendvai
yeah, i'm right at that point with maru where image saving/loading is becoming unavoidable, short of some novel magic
23:56:30
attila_lendvai
drmeister, maru has a naive precise GC without threads. for now it's pretty much orthogonal to llvm.
23:59:55
Bike
i see the downside of being more concrete is that there are more than like five source files
0:13:54
drmeister
Dammit - I think I have to start putting print statements into llvm to figure out what is going on.
2:48:50
drmeister
Something has changed with the policy. I put in enough print statements to see the different flow control in llvm9 vs llvm12
2:50:56
Bike
if we specifically request that frame points aren't removed, but they're removed anyway, that seems like a bug
2:52:28
drmeister
https://github.com/llvm/llvm-project/blob/release%2F12.x/llvm/lib/Target/X86/X86FrameLowering.cpp#L93
2:53:38
drmeister
Hmm - it's a big OR block - it's got more terms in it than llvm9. You'd think it would generate FP more often rather than less.
2:55:36
drmeister
For the functions missing the FP - the hasFP function is returning true in llvm9 and false in llvm12
3:42:06
drmeister
I dump all the terms in that big OR block in llmv9 and llvm12 - here's a typical llvm9 case...
3:55:31
drmeister
https://github.com/llvm/llvm-project/blob//llvm/lib/CodeGen/TargetOptionsImpl.cpp#L24
3:56:32
drmeister
https://github.com/llvm/llvm-project/blob/release%2F12.x/llvm/lib/CodeGen/TargetOptionsImpl.cpp#L24
3:57:13
drmeister
I think llvm is moving away from disabling disable-frame-pointer to frame-pointer=all
3:57:14
Bike
https://github.com/llvm/llvm-project/commit/03b9f0a5e19aa68fb0a82d80e409333db7ee511c ah, they did rename it.
3:58:23
Bike
https://github.com/llvm/llvm-project/commit/b7cef81fd36c85e52b115b9ed6d1fb92d63781d6 two years ago! golly
4:20:29
drmeister
Right - analyzing 125 million lines of C++ to figure out what classes have vtables
5:00:19
drmeister
To identify within every class the offset of every pointer that needs to be fixed by the garbage collector. I've just added the ability to determine if the C++ class has a vtable pointer.
5:00:47
drmeister
Because the image save/load needs to be able to restore all of the vtable pointers at load-time.
5:01:17
drmeister
I have lots of pointers into the C++ generated code that I need to restore at load-time.
5:02:58
drmeister
It's going to be like ripping apart a piece of cloth and then putting it back together at load-time.
5:04:05
drmeister
The added challenge is that the C++ generated code and libraries may be at a different location at load-time than they were at save-time.
5:05:33
drmeister
But I'm certain that I can depend on all of the pointers to addresses in a particular library at load-time remaining at the same offset relative to the start of the library at save-time.
5:08:25
drmeister
Hmm, I better talk with cracauer about that. That may be too strict a restriction.
5:15:05
beach
So the plan is to not save shared libraries, and instead to load them again when the saved image is executed?
5:16:46
drmeister
I can't save arbitrary objects. I'm going to limit it to clasp/cando objects. In that case it may turn out that it's only the executable that I need to worry about.
5:17:48
drmeister
My function entry points now involve a level of indirection that keeps track of what executable/library the entry point points in to.