Re: Redundant type checking in window.c and w32menu.c

[Ken Raeburn]

On Jun 20, 2007, at 16:46, Jason Rumney wrote:
> Is this optimisation really worth the confusion of having two versions
> of these functions in the code?

We could use a new macro DEFUN_INLINE, like so:

#if CAN_DO_INLINE || defined PROVIDE_ADDRESSABLE_IMPLEMENTATION
DEFUN_INLINE ("car", Fcar, Scar, ....)
  (list)
  Lisp_Object list;
{
  ...;
}
#else
EXFUN(Fcar, 1);
#endif

where:

PROVIDE_ADDRESSABLE_IMPLEMENTATION: Is defined in exactly one Emacs  
source file, say, data.c, before lisp.h is included.

CAN_DO_INLINE: Is true if the compiler, with the current options,  
supports inline functions in some useful form.  (E.g., it could  
expand to test __GNUC__, __OPTIMIZE__, __STDC_VERSION__, etc.)  For  
brevity, we could also define a macro that tests both this property  
and PROVIDE_ADDRESSABLE_IMPLEMENTATION.

DEFUN_INLINE: If inline functions are not supported, expands to the  
same as DEFUN.  Otherwise, tests PROVIDE_ADDRESSABLE_IMPLEMENTATION  
and makes an addressable version if it's defined, and an inline  
version if not.  Depending on the compiler, "inline", "static  
inline", "extern inline", or other keywords may be used.

In older GCC compilers, "extern inline" means "expand inline or  
generate a reference to an external copy defined elsewhere, but don't  
provide an external definition or static copy", while "inline" would  
produce an external definition.  ISO C 99 has a different meaning for  
"extern inline", in fact I think the handling of "extern inline" and  
"inline" may be almost exactly reversed from the old GCC handling,  
and GCC is adapting to the spec but providing some attributes for  
finer control I think.  Using "static inline" sidesteps the issue but  
risks producing multiple static copies of the function if it's not  
expanded inline.  But there are also GCC version number macro tests  
and autoconf feature test cases possible.  This could make defining  
DEFUN_INLINE a little bit complicated, but the use of it should be  
pretty straightforward.

Then, data.o gets an addressable copy of the function for use in  
defining the Lisp symbol, and it can be expanded inline in other  
source files when the compiler supports it.  Debuggers on some older  
platforms may not handle functions defined in header files very well,  
but with inline expansion happening, you're not likely to be able to  
set breakpoints in these functions usefully anyways.

(On a vaguely related note, is it time to start assuming at least  
ANSI C '89 support, like prototypes, in the Emacs sources yet?)

Ken