> Date: Mon, 12 May 1997 15:10:13 +0200 (MET DST)
> From: Andrew Walker <andy@lysaker.kvaerner.no>
>
> Me! I know, because I wrote it :-) My understanding of the GCC
> documentation was that by doing it this way I would get the effect
> of inlining the function everywhere it is possible to inline it,
> but the function would still be emitted in locks.o in case some
> weird usage meant that inlining couldn't occur. Am I wrong? Is this
> a problem?
>
> You have to code up a serious monster for gcc to not inline it when
> optimizations are enabled (there are 200 line functions in the Sparc
> ESP scsi driver which GCC inlines just fine, there are about 5 or 6 of
> there which all get inlined into the interrupt service function, sick
> and perhaps stupid, but an example that gcc is really good at this).
>
> The rule of thumb is, if you think there is even a possibility that
> your inline function is complex enough that gcc may toss trying to
> inline it, rethink your inline function. ;-) Otherwise just assume gcc
> will always get it and inline it properly, if for some reason it
> doesn't some day, you'll get linker errors to wake you up to the fact
> ;-)
>
Point taken Dave. In the particular case of locks_verify_locked() I
was concerned that some, as yet unknown code, for example an fs module,
would try to use the address of the function or something like that. I
wasn't worried about the complexity of the function itself ('cos its dead
simple ;-)
-Andy
Andy Walker Kvaerner Engineering a.s.
Andrew.Walker@lysaker.kvaerner.no P.O. Box 222, N-1324 Lysaker, Norway
......if the answer isn't violence, neither is your silence......
(pwei barmy army - oslo "filial")