RFC: INLINE defcfun and auto FTYPE declarations [with patch]

Luís Oliveira luismbo at gmail.com
Wed Nov 8 00:12:49 UTC 2017


On Mon, Nov 6, 2017 at 5:10 PM, Andrzej Walczak
<andrzejwalczak at google.com> wrote:
> After some thoughts, I agree, that the inlining control is not a fully-baked
> idea, yet.

Incidentally, this recent pro at c-l.net message makes me a whole lot
less skeptical about your suggested approach:
<https://mailman.common-lisp.net/pipermail/pro/2017-November/001464.html>.
The introspect-environment library seems to provide a nice portable
API for inspecting optimization policies. Alas, there doesn't seem to
be away to define your own declarations; I was hoping we might be able
to something like (declaim (inline-cffi-functions <boolean>)) or
something along those lines.


> I'll split the patch into INLINE and FTYPE parts.

Sounds like a good idea.


> You may ask why we have decided to inline (almost) every of the DEFCFUNs?
> CFFI interfaces to C - obviously - and a lot of code in C deals with
> double-floats and 64-bit integers.
> Without the stubs being inline, every call to C and back produces boxed
> values, impacting the performance.

Right. Float boxing; that's a classic. But, I (perhaps naively) didn't
expect boxing to happen even without the declarations. Take the
following example:

(in-package :cffi)

(declaim (optimize (speed 3) (space 0) (safety 0) (debug 0)))

(declaim (inline fabs-1))
(defun fabs-1 (x)
  (foreign-funcall "fabs" :double x :double))

(declaim (inline fabs-2))
(defun fabs-2 (x)
  (declare (double-float x))
  (foreign-funcall "fabs" :double x :double))

(defun foo-1 (x)
  (floatp (fabs-1 x)))

(defun foo-2 (x)
  (floatp (fabs-2 x)))

I expected FABS-1 and FABS-2 to be identical. (FOREIGN-FUNCALL
eventually expands to ALIEN-FUNCALL and I was expecting that would
provide all the type information SBCL's compiler might need.) The
disassembly shows that FAB-2 is one instruction shorter. But
disassembling FOO-1 and FOO-2 shows that they're identical.

Perhaps this example is too contrived. Do you have a better one?

Cheers,

-- 
Luís Oliveira
http://kerno.org/~luis/



More information about the cffi-devel mailing list