Messages in this thread | | | Date | Tue, 13 May 1997 09:47:11 +0200 (MET DST) | From | Andrew Walker <> | Subject | Re: sockfd_lookup |
| |
On Mon, 12 May 1997, David S. Miller wrote:
> 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")
| |