freenode/#clasp - IRC Chatlog
Search
22:50:39
drmeister
For some reason we call add_dynamic_library_using_handle(...) from core__load_binary(...) and I'm thinking of completely removing core__load_binary(...), which would remove the call to add_dynamic_library_using_handle(...), which would start tear out some code from both debug_unixes.cc and debug_macos.cc
22:51:37
drmeister
If I remove core__load_binary(...) then I can remove all the clasp and wscript code that links .fasl (.so/.dylib) files.
22:52:50
drmeister
It would remove the CLASP_BUILD_MODE="fasl", which we haven't used in about a year.
22:53:48
drmeister
That would close off the idea of using LTO for optimization - but it doesn't work properly without a lot more work.
22:54:25
drmeister
I'm thinking for optimization we go in a different direction - we implement beach's call site optimization. That works with the faso/fasp files fine.
22:56:03
drmeister
We could do call site optimization to have Common Lisp code call C++ code that takes doubles directly.
22:57:20
drmeister
If we know a C++ function takes a double and we call it from CL and we have the value in an unboxed double - then we can create a call-site that takes it from wherever it is in the CL function and put it in whatever double register the callee needs.
23:07:22
drmeister
My basic point is I think with faso files and call site optimization we can get the kind of performance that we could get with LTO and in a much more flexible/lispy way.
23:22:52
Bike
the c++ functions are static, so i would think we can do that without the call site optimization? just generate calls with the unboxed parameters