On Tue, Oct 2, 2012 at 1:14 PM, Matthew Mondor <mm_lists@pulsar-zone.net> wrote:
I noticed many calls to ecl_to_pointer() expanding to
ecl_foreign_data_pointer_safe() calls even with (optimize (safety 0)).
But interestingly in cmp/sysfun.lsp, I saw the following line:

(def-inline si:foreign-data-p :always (t) :bool "@0;ECL_FOREIGN_DATA_P(#0)")

Note the "-p". This is a type predicate, which only checks whether a lisp object contains a pointer or not.

ecl_to_pointer() is a C macro and expands to the *_safe version internally. C compilation is not conditioned by lisp proclamations.

I also noticed that my DECLAIM to inline the accessor functions do not
appear to work, so there also always are function calls made to
access/set structure fields no matter the SPEED/SAFETY level.  This is
not terrible, although if such small functions could be inlined it'd be
nice.  Since the inline declamations appeared to work in other contexts
for small functions, I wondered if perhaps it's a limitation of
functions using C-INLINE.

The thing is that ECL does not keep code across compilations and not even in compiled images. This means that the INLINE declaration is not useful right now outside the same file (but even then, I am not sure when it is active. I would have to look it up)
 I also thought about perhaps generating small C functions with the inline directive via CLINES instead of using C-INLINE too, which could be another approach (I'd also have to check how to get those to register CL symbols and be ECL friendly then).

When I really want to inline something portably I use compiler macros. DEFINE-COMPILER-MACRO allows you to define more precisely the expansion you want and is the mechanism used by ECL's optimizer right now.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)