CLHS: Issue ALLOW-LOCAL-INLINE Writeup

#

## Issue ALLOW-LOCAL-INLINE Writeup

    Forum:		Compiler
    Issue:		ALLOW-LOCAL-INLINE
    References:	CLtL p. 156, 159
    Related issues: PROCLAIM-INLINE-WHERE
    Category:	CLARIFICATION
    Edit History:   21 Sept. 88 V1 by David Gray
                    27 Oct.  88 V2 by David Gray - new proposal
    		 9 Nov.  88 V3 by David Gray - expanded problem
    			description and discussion sections.
    		30 Dec.  88 V4 by Sandra Loosemore -- suggestions from Pitman

    Problem Description:

      The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
      on 10/12/88) clarifies the use of INLINE proclamations, but there
      remains a similar problem with the use of a local (DECLARE (INLINE
      ...)):  how can the compiler expand the function inline if it didn't
      know that the necessary information should have been saved when the
      function was compiled?

      Note that an INLINE proclamation does two things:

        (1) It tells the compiler to do extra things when it sees the
            function -definition-, to make it possible to code the function
    	inline.

        (2) It tells the compiler to code -calls- to the function inline.

      In order for local INLINE declarations to be useful, we need part 1
      without part 2.

    Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE

      Clarify that to define a function FOO which is not INLINE by default
      but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
      the proper definition sequence is:

       (PROCLAIM '(INLINE foo))
       (DEFUN foo ...)
       (PROCLAIM '(NOTINLINE foo))

      The INLINE proclamation preceding the DEFUN ensures that compiler will
      save the information necessary for inline expansion, and the NOTINLINE
      proclamation following the DEFUN prevents it from being expanded
      inline everywhere.

      Note that while implementations are never required to perform inline
      expansion of function calls, many implementations that do support
      inline expansion will not be able to respond to local INLINE requests
      if this technique is not followed.

     Rationale:

      Local INLINE declarations are of little use without some way of
      alerting the compiler to the possibility of inline expansion before
      the function is compiled.  This seems the simplest solution since it
      just clarifies existing practice instead of adding a new feature to
      the language.

      A compiler could use some heuristic to save the definitions of functions
      that are short enough to look like good candidates for inline expansion,
      but then the user is never sure what to expect.  It is possible that a
      compiler could simply save all definitions (assuming availability
      of adequate storage space) but we shouldn't require that.

     Test Cases/Examples:

      Given the following input to COMPILE-FILE, does F1 get expanded inline
      in F2, and does F3 get expanded inline in F4?

        (defun f1 (a) (+ a 100))
        (defun f2 (b) (declare (inline f1)) (f1 b))
        (proclaim '(inline f3))
        (defun f3 (a) (+ a 100))
        (proclaim '(notinline f3))
        (defun f4 (b) (f3 b))			;F3 is not inline.
        (defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
        (defun f6 (c) (f3 c)) 			;The local effect is not
    						;  persistent.

     Current Practice:

      In the example above, using Symbolics, Lucid, or Explorer, F1 is not
      expanded in F2, but F3 is expanded in F5.

     Cost to implementors:

      None, since this is a clarification in accordance with current
      practice.

     Cost to users:

      None.

     Benefits:

      Users will be able to use (DECLARE (INLINE ...)) with greater assurance
      that it will really do something.

     Costs of Non-Adoption:

      Users will not know how to reliably request inline expansion on a
      local basis.  This technique is not obvious, and even the need
      for it likely to be apparent only to people who understand something
      about how the compiler does inline expansion.

     Discussion:

      Version 1 of this issue included proposal
      ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
      language:
        (PROCLAIM '(ALLOW-INLINE foo))
      This was met with a lack of enthusiasm since it was pointed out that
      the same effect could be obtained by using a combination of INLINE and
      NOTINLINE.

      This is may not be completely true, however, since people's thinking
      about NOTINLINE has evolved in the direction of a declaration that
      tells the compiler "assume nothing about this function".  Thus, a
      NOTINLINE proclamation might suppress some optimizations that would
      have occurred if there had never been an INLINE and NOTINLINE.

      Ideally, it would be nice to have multiple levels of control instead
      of just INLINE or NOTINLINE -- something like:
        * always inline
        * maybe inline (let the compiler decide)
        * just save the definition for possible local inline
        * default
        * never inline

      Pitman has said that he generally approves of the direction of this
      proposal, but he has also expressed concerns about how the persistance
      of INLINE proclamations may cause confusion when functions are redefined
      in an incremental development environment.

Copyright 1996-2005, LispWorks Ltd. All rights reserved.