freenode/#clasp - IRC Chatlog
Search
15:02:40
drmeister
And in cl-wrappers.lisp is: (generate-direct-call-defun (core:magic-intern "cl__cons") (object1 object2) "wrapped_cl__cons" )
15:04:05
drmeister
And wrapped_cl__cons translates the arguments - which shouldn't be anything in this case, just wrap the core::T_O* in a T_sp
15:09:21
drmeister
I think that was so that these wrapped functions wouldn't override our cleavir inline versions
15:11:14
Bike
so, i mean, this lisp function isn't inlined. so (cons 'a 'b) calls a lisp function, which multiple-value-foreign-calls wrapped_cl__cons, which finally calls cl__cons?
15:12:49
drmeister
Yes - and the the core:multiple-value-foreign-call can cause the wrapped_cl__cons to be inlined in the lisp function via LTO and the core::cl__cons function can be inlined in the wrapped_cl__cons via LTO.
15:14:55
drmeister
Right - now this is assuming all this stuff is working and LTO is working as it should.
15:15:37
drmeister
We can verify it if we compile-file some test code and link it to fasls while saving the llvm LTO temp files.
15:16:17
drmeister
LTO kind of does it's think when clang runs on the final link product. But it's set up to turn on a flag that saves the intermediate optimized bitcode files.
15:22:34
drmeister
There can be no variadic functors in calls involving these functions. If there are - then something is wrong.
15:25:28
drmeister
My reading of the C++ rules and my occasional tests tell me that T_sp should be passed by value in a single pointer and that creating them and using T_sp x; x.raw_() or x.rawRef_() should be zero cost.
15:48:35
drmeister
cclasp appears to be building fine. I'll push to testing and get some timing - now with direct-calls turned on.
15:53:29
drmeister
The other thing is to make sure LTO is on and that I haven't left something else disabled or some other debugging flags on that could be slowing things down.
15:55:38
drmeister
And there are a lot of calls that aren't being wrapped at the moment - investigating...
15:59:10
drmeister
The 'cclasp-boehm' executable is the executable that has everything inlined as well as it can be.
15:59:54
drmeister
the 'iclasp-boehm' executable relies on calls from the Common Lisp code to the C++ code - but not through VariadicFunctor - straight up calls.
16:09:11
drmeister
No - they do. What you don't get is (in the case of cl__cons) the LTO inlining of the core::cl__cons into the wrapped_cl__cons
16:11:16
drmeister
Uh - I misspoke. core::cl__cons can be inlined in wrapped_cl__cons - thats all on the C++ side. You are correct wrapped_cl__cons won't be inlined into cl:cons
16:13:29
drmeister
We would need to LTO link a 'bclasp-boehm' if we wanted to take advantage of LTO for building.
16:16:30
drmeister
We could get a measure of the value by timing compile-file using 'iclasp-boehm' vs 'cclasp-boehm'
16:32:15
drmeister
Rather, the function signature is appearing somewhere earlier - in a C++ header somewhere.
16:40:41
Bike
well, if the externs are for stuff like normalize triple that we don't call very much, that's kind of dumb but probably tolerable?
17:06:38
drmeister
CL_EXTERN_DEFUN((llvm::ConstantInt *(*)(llvm::LLVMContext &, const llvm::APInt &)) &llvm::ConstantInt::get);
17:07:35
drmeister
I have to provide the function signature in some cases to select between C++ overloads.
17:08:23
drmeister
It's a good idea because if the function signature changes in the header file - then there will be a C++ compile time error and then we have to fix things - that's pretty normal.
17:09:36
drmeister
For a definition like this: CL_EXTERN_DEFUN( &llvm::Type::getInt64Ty); the function signature can change in the C++ code and only be discovered in a call from Common Lisp.
17:10:17
drmeister
So, what if we provide the function signature for all of these CL_EXTERN_DEFUN's in the form of the pointer cast and parse them - then we can generate wrappers.
17:10:48
drmeister
It's only a few dozen changes and there is already a C++ function signature parser in the scraper.
17:15:26
drmeister
Once we convert CL_DEFMETHOD to generic function wrappers we can do these as well if they have signatures.
17:20:13
drmeister
The pointer type info is recorded in the tag and that can be used to construct a signature.
17:20:32
drmeister
{ TAGS:CL-EXTERN-DEFUN-TAG ((TAGS:FILE% . "/Users/meister/Development/clasp/src/llvmo/llvmoExpose.cc") (TAGS:LINE% . 2005) (TAGS:CHARACTER-OFFSET%) (TAGS:POINTER% . "(llvm::ConstantFP *(*)(llvm::LLVMContext &, const llvm::APFloat &)) &llvm::ConstantFP::get"))}
20:41:07
drmeister
I learned enough esrap to be dangerous and wrote an esrap parser for C++ function pointer syntax.
20:49:22
drmeister
And: (convert-function-ptr-to-c++-types (esrap:parse 'function-ptr "(llvm::ConstantFP *(*)(llvm::LLVMContext &, const llvm::APFloat &)) &llvm::ConstantFP::get"))
2:20:53
nicholas
thanks for responding. My question is how small and efficient does CLASP compile down to as standalone executables? I am looking for a lisp that will bundle into a small library for inclusing in mobile applications.?
2:21:42
Bike
among other problems, clasp is x86 64 only at the moment, you can't use it on an arm phone or anything
2:27:20
drmeister
Bike: The parser for pointer types is working now - when you provide the pointer type - then it creates a wrapper function. I added pointer types for all of the type functions