[PATCH] Inline vfat_strnicmp()

[PATCH] Inline vfat_strnicmp()

[Ren]

Hi,

the function vfat_strnicmp() has just one callsite. Inlining it
actually shrinks vfat.o slightly.

René



diff -u ./fs/vfat/namei.c~ ./fs/vfat/namei.c
--- ./fs/vfat/namei.c~	2003-07-27 16:41:36.000000000 +0200
+++ ./fs/vfat/namei.c	2003-07-27 17:12:12.000000000 +0200
@@ -103,7 +103,7 @@
 	return nc ? nc : c;
 }
 
-static int
+static inline int
 vfat_strnicmp(struct nls_table *t, const unsigned char *s1,
 					const unsigned char *s2, int len)
 {

Re: [PATCH] Inline vfat_strnicmp()

[OGAWA Hirofumi]

Ren <l.s.r@web.de> writes:

> the function vfat_strnicmp() has just one callsite. Inlining it
> actually shrinks vfat.o slightly.

Thanks. I'll submit this patch to Linus.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Inline vfat_strnicmp()

[Denis Vlasenko]

On 27 July 2003 19:33, OGAWA Hirofumi wrote:
> Ren <l.s.r@web.de> writes:
> 
> > the function vfat_strnicmp() has just one callsite. Inlining it
> > actually shrinks vfat.o slightly.
> 
> Thanks. I'll submit this patch to Linus.

Just to deinline it in some months?

Come on, automatically inlining static functions with
just one callsite is a compiler's job. Don't do it.
--
vda

Re: [PATCH] Inline vfat_strnicmp()

[OGAWA Hirofumi]

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:

> On 27 July 2003 19:33, OGAWA Hirofumi wrote:
> > Ren <l.s.r@web.de> writes:
> > 
> > > the function vfat_strnicmp() has just one callsite. Inlining it
> > > actually shrinks vfat.o slightly.
> > 
> > Thanks. I'll submit this patch to Linus.
> 
> Just to deinline it in some months?
> 
> Come on, automatically inlining static functions with
> just one callsite is a compiler's job. Don't do it.

Unfortunately "gcc version 3.2.3 20030415 (Debian prerelease)"
doesn't, at least.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Inline vfat_strnicmp()

[David Weinehall]

On Thu, Jul 31, 2003 at 10:52:23PM +0900, OGAWA Hirofumi wrote:
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
> 
> > On 27 July 2003 19:33, OGAWA Hirofumi wrote:
> > > Ren <l.s.r@web.de> writes:
> > > 
> > > > the function vfat_strnicmp() has just one callsite. Inlining it
> > > > actually shrinks vfat.o slightly.
> > > 
> > > Thanks. I'll submit this patch to Linus.
> > 
> > Just to deinline it in some months?
> > 
> > Come on, automatically inlining static functions with
> > just one callsite is a compiler's job. Don't do it.
> 
> Unfortunately "gcc version 3.2.3 20030415 (Debian prerelease)"
> doesn't, at least.

And how big is the performance loss?  Is it even measurable?
And even if it is, is optimizing this really worth the trouble?


Regards: David Weinehall
-- 
 /) David Weinehall <tao@acc.umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/

Re: [PATCH] Inline vfat_strnicmp()

[Denis Vlasenko]

On 31 July 2003 16:52, OGAWA Hirofumi wrote:
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
> 
> > On 27 July 2003 19:33, OGAWA Hirofumi wrote:
> > > Ren <l.s.r@web.de> writes:
> > > 
> > > > the function vfat_strnicmp() has just one callsite. Inlining it
> > > > actually shrinks vfat.o slightly.
> > > 
> > > Thanks. I'll submit this patch to Linus.
> > 
> > Just to deinline it in some months?
> > 
> > Come on, automatically inlining static functions with
> > just one callsite is a compiler's job. Don't do it.
> 
> Unfortunately "gcc version 3.2.3 20030415 (Debian prerelease)"
> doesn't, at least.

Yes, but some future version would.

Since there is no substantial wins in hunting down
such statics, and there is some risk of code bloat when
big inlined statics get called from more that one callsite,
and it will be automatically handled by smarter compiler someday,
I think it makes perfect sense to avoid doing this.
--
vda

Re: [PATCH] Inline vfat_strnicmp()

[OGAWA Hirofumi]

David Weinehall <tao@acc.umu.se> writes:

> And how big is the performance loss?  Is it even measurable?
> And even if it is, is optimizing this really worth the trouble?

48bytes smaller than prev. I think It's not a clear reason for
rejecting a patch.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Inline vfat_strnicmp()

[OGAWA Hirofumi]

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:

> Yes, but some future version would.
> 
> Since there is no substantial wins in hunting down
> such statics, and there is some risk of code bloat when
> big inlined statics get called from more that one callsite,
> and it will be automatically handled by smarter compiler someday,
> I think it makes perfect sense to avoid doing this.

Could you tell me, if compiler does it in future? I'll gladly kill
that inline.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: [PATCH] Inline vfat_strnicmp()

[Denis Vlasenko]

On 31 July 2003 18:07, OGAWA Hirofumi wrote:
> Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
> 
> > Yes, but some future version would.
> > 
> > Since there is no substantial wins in hunting down
> > such statics, and there is some risk of code bloat when
> > big inlined statics get called from more that one callsite,
> > and it will be automatically handled by smarter compiler someday,
> > I think it makes perfect sense to avoid doing this.
> 
> Could you tell me, if compiler does it in future? I'll gladly kill
> that inline.

I can't be 100.00% sure it will happen. I'd say 98.234235% ;)

Andrew Morton kills extra large inlines, and you are creating them :(
That's not ok. Just leave those poor static functions alone
until compiler will do them, all at once.
There are lots of other stuff to do in the kernel source.
--
vda

Re: [PATCH] Inline vfat_strnicmp()

[OGAWA Hirofumi]

Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:

> I can't be 100.00% sure it will happen. I'd say 98.234235% ;)
> 
> Andrew Morton kills extra large inlines, and you are creating them :(
> That's not ok. Just leave those poor static functions alone
> until compiler will do them, all at once.
> There are lots of other stuff to do in the kernel source.

 - That's smaller than prev in *real world*.
 - You don't fix compiler.

End of story.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>