Re: Inlining can be _very_bad...

On Fri, Mar 30, 2007 at 12:01:11AM +0200, J.A. Magallón wrote:
On Thu, 29 Mar 2007 19:52:54 +0200, Adrian Bunk <bunk@xxxxxxxxx> wrote:

On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote:
Hi all...

I post this here as it can be of direct interest for kernel development
(as I recall many discussions about inlining yes or no...).

Testing other problems, I finally got this this issue: the same short
and stupid loop lasted from 3 to 5 times more if it was in main() than
if it was in an out-of-line function. The same (bad thing) happens if
the function is inlined.
...
It looks like is updating the stack on each iteration...This is -march=opteron
code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.

tst.c and Makefile attached.

Nice, isn't it ? Please, probe where is my fault...

The only fault is to post this issue here instead of the gcc Bugzilla.

Sorry, my intention was just something like 'take a look at your
reduction-like code, perhaps its sloooow', something like checksum
funtions in tcp or raid that are inlined expecting to be faster
and in fact they are slower...

Unless a function that has more than 1 caller is very tiny or reduces at
compile time to a very tiny rest, it's not expected that inlining was
faster on current CPUs.

But most times that's already only up to the compiler - e.g. current gcc
versions already automatically inline all static functions with only
1 caller.

In your example the compiler should produce code not slower than with
the out-of-line version when inlining. If it doesn't the bug in the
compiler resulting in this should be fixed.

That's what I expected, but...
Going to gcc bugzilla...

Thanks.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Inline assembler reference
    ... I do know how to beat the compiler with float/SSE* instructions. ... CALL instruction most of the time when inlining it could avoid those ... The Intel and GCC ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
    ... >> with hope that some new gcc probably will inline it anyway (on some ... > Just use `inline'. ... > uninlined by the compiler if someone adds a second callsite later on. ... i believe the opposite is true: inlining is arguably best done ...
    (Linux-Kernel)
  • Re: [PATCH] prepare kconfig inline optimization for all architectures
    ... we continue to force the compiler to always inline with "inline" ... ignoring the fact that nobody should really expect the compiler to always ... inlining is about much more than pure optimization. ... I have vey often cursed gcc inlining some biggish function - who the f*ck ...
    (Linux-Kernel)
  • FreeBSD 7.0 using GCC 4?
    ... I just updated one of my 6.2-STABLE machines to 7.0-CURRENT and was expecting to see gcc 4.x as the default compiler... ...
    (freebsd-current)
  • Re: [PATCH] xfs: reduce stack usage in xfs_bmap_btalloc()
    ... You should mark the helper noinline just to prevent gcc from possibly ... inlining it. ... Even if it doesn't with your current compiler inline heuristics ...
    (Linux-Kernel)