What cases it might be necessary to declare function an NOTINLINE in ?
Here is the excerpt ion ion from MaiSQL code
(defun crypt-password (password salt)
"Encrypt a password for transmission to a PostgreSQL server."
(declare (notinline system:foreign-symbol-address))
(unless (ignore-errors (system:foreign-symbol-address *crypt-function-name*))
(ext:load-foreign *crypt-library*))
(alien:alien-funcall
(alien:sap-alien
(system:foreign-symbol-address *crypt-function-name*)
(alien:function c-call:c-string c-call:c-string c-call:c-string))
password salt))
What would happen if DECLARE wasn't present ?
--
Vladimir Zolotykh
In article <·················@eurocom.od.ua>,
Vladimir Zolotykh <······@eurocom.od.ua> wrote:
>What cases it might be necessary to declare function an NOTINLINE in ?
>Here is the excerpt ion ion from MaiSQL code
>
>(defun crypt-password (password salt)
> "Encrypt a password for transmission to a PostgreSQL server."
> (declare (notinline system:foreign-symbol-address))
> (unless (ignore-errors (system:foreign-symbol-address *crypt-function-name*))
> (ext:load-foreign *crypt-library*))
> (alien:alien-funcall
> (alien:sap-alien
> (system:foreign-symbol-address *crypt-function-name*)
> (alien:function c-call:c-string c-call:c-string c-call:c-string))
> password salt))
>
>What would happen if DECLARE wasn't present ?
Loading that library probably modifies the definition of
SYSTEM:FOREIGN-SYMBOL-ADDRESS. If it were expanded inline, the change
wouldn't affect the call later in the function.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> Vladimir Zolotykh <······@eurocom.od.ua> wrote:
> >
> > What cases it might be necessary to declare function an NOTINLINE
> > in ?
>
> Loading that library probably modifies the definition of
> SYSTEM:FOREIGN-SYMBOL-ADDRESS. If it were expanded inline, the
> change wouldn't affect the call later in the function.
Also, I've used notinline declarations when I wanted to trace a
recursive function where the compiler was eliminating tail calls,
causing only the top-level call to the function to be traced (this was
in MCL).
John Wiseman
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> What cases it might be necessary to declare function an NOTINLINE in ?
> Here is the excerpt ion ion from MaiSQL code
>
> (defun crypt-password (password salt)
> "Encrypt a password for transmission to a PostgreSQL server."
> (declare (notinline system:foreign-symbol-address))
> (unless (ignore-errors (system:foreign-symbol-address *crypt-function-name*))
> (ext:load-foreign *crypt-library*))
> (alien:alien-funcall
> (alien:sap-alien
> (system:foreign-symbol-address *crypt-function-name*)
> (alien:function c-call:c-string c-call:c-string c-call:c-string))
> password salt))
>
> What would happen if DECLARE wasn't present ?
In this particular case, the notinline declaration is there to prevent
CMUCL from applying some of its optimizations that can result in the
whole unless statement being rendered useless:
In CMUCL system:foreign-symbol-address is known to be flushable (for
reasons of efficiency):
(defknown foreign-symbol-address (simple-string) system-area-pointer
(movable flushable))
that means that if the return values of f-s-a are known by the
compiler not to matter, it can simply elide the call to f-s-a. Since
we also know that f-s-a always returns a system-area-pointer (_IF_ it
returns), we can deduce that no matter what it returns, it will result
in the condition not being nil. So it elides the call to f-s-a, and
the ignore-errors form becomes, for all intents and purposes
(ignore-errors <some-sap-which-is-not-nil>)
which is always going to be true, hence the unless form is rendered
useless.
By declaring f-s-a notinline, we disallow the compiler to flush the
call to f-s-a.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein