[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue ALLOW-LOCAL-INLINE
- To: cl-compiler@sail.stanford.edu
- Subject: Re: issue ALLOW-LOCAL-INLINE
- From: masinter.pa@Xerox.COM
- Date: 5 Jan 89 20:57 PST
- Cc: masinter.pa@Xerox.COM
- In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 3 Jan 89 15:23:02 MST
I don't like this at all. I'd prefer to see compilers sweat to
automatically go back and grab the definition if you say
(declare (inline frobnicate))
somewhere way after frobnicate was defined.
That is
"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."
isn't really true if compilers worked harder.
However, as you say, this reflects current practice. I think I'd like the
ALLOW-INLINE proclaimation instead.
That is, of the multiple levels of control
* always inline
* maybe inline (let the compiler decide)
* just save the definition for possible local inline
* default
* never inline
I don't see a need for distinguishing between
* always inline
and
* maybe inline (let the compiler decide)
since "always inline" really means "let the compiler decide" anyway. The
control over the compilers heuristics are more portably controlled via the
SPACE vs SPEED parameters, are they not?
I also don't see a need for distinguishing between "default" and "never
inline", since the default *is* never inline, is it not?
This leaves us with three possibilities: INLINE, NOTINLINE and
ALLOW-INLINE.