Issue ALLOW-LOCAL-INLINE

[David N Gray <Gray@DSG.csc.ti.com>]

Issue:		ALLOW-LOCAL-INLINE
References:	CLtL p. 156, 159;
		Issue PROCLAIM-INLINE-WHERE
Category:	ADDITION
Edit History:   22 Sept. 88, V1 by David Gray
Status:		For preliminary discussion 
 
Problem Description:

  The proposal PROCLAIM-INLINE-WHERE:BEFORE 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?
 
Proposal ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE
 
  Add a new declaration, ALLOW-INLINE, which can only be used in a
  PROCLAIM.  (PROCLAIM '(ALLOW-INLINE {function-name}+)) means that when
  the compiler compiles a subsequent definition of a function whose name
  is listed here, it should record whatever information it would need in
  order to obey a local (DECLARE (INLINE ...)) for that function.
  (An implementation that ignores INLINE declarations can also ignore
  ALLOW-INLINE proclamations.)  A NOTINLINE proclamation cancels the
  effect of an ALLOW-INLINE proclamation.

  If there is a local INLINE declaration for a function which was compiled
  without either an INLINE or ALLOW-INLINE proclamation in effect, then it
  is implementation-dependent whether inline expansion is actually done.

 Rationale:

  Local INLINE declarations are of little use without this capability.
  A compiler could just save the definitions of all functions if memory
  space wasn't a problem, but it usually is.  Or, 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.

 Test Cases/Examples: 

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

    (defun f1 (a) (+ a 100))
    (defun f2 (b) (declare (inline f1)) (f1 b))
 
 Current Practice:
 
  There is no known implementation of this proposal.  The Explorer has an
  undocumented proclamation used internally that is similar to this, and
  remembers trivially short functions when SPEED is greater than SAFETY.

  In the example above, inline expansion is not done on Explorer,
  Symbolics, or Lucid, although they all do support inline expansion
  when proclaimed globally.

 Cost to implementors:
 
  Trivial.

 Cost to users:
  
  None.

 Benefits:

  Users will be able to use (DECLARE (INLINE ...)) and have more
  confidence that it will really do something.

 Costs of Non-Adoption: 

  Inability to reliably request inline expansion on a local basis.

 Discussion:

  The name ALLOW-INLINE was suggested by Rob MacLachlan back on March 2,
  1987.

  It could be said that since implementations are free to ignore INLINE
  declarations, it is unimportant whether a particular inline
  declaration really has any effect.  However if a user added the inline
  declaration because he is trying to speed up some time-critical code,
  and he knows that his compiler supports inline expansion, he would
  like to be able to know that it really is going to happen when he
  wants it to.  There may be other reasons why the compiler decides that
  inline expansion is not appropriate in a particular case, but this
  proposal would eliminate the biggest uncertainty factor.