Re: Function Pointers and Inlining

From: Victor Bazarov (v.Abazarov_at_comAcast.net)
Date: 03/22/05 

Date: Tue, 22 Mar 2005 13:46:20 -0500

James Aguilar wrote:
> "Howard" <alicebt@hotmail.com> wrote in message
> news:YzY%d.162941$Th1.160178@bgtnsc04-news.ops.worldnet.att.net...
>
>>Never? I don't think that's correct. If I recall, the implementation is free
>>to inline those calls which it is able to inline. But it must also provide a
>>non-inline version which can be called normally. It's not an all-or-nothing
>>thing, but is handled on a case-by-case basis. At least, that's my
>>understanding.
>
>
> I've been wrong before, but I think I read something about how if you take the
> address of a particular function, that function won't be inlined elsewhere. A
> test shows . . .
>
> --- CODE ---
[...]
> --- CODE ---
>
> I think that if it worked as you say, LINK 1 would be addl $5, %eax or something
> like that. On the other hand, when I get the assembly compiling with -O2, crazy
> stuff happens and I can't read it.

You're arguing different points here. Howard says what the Standard says.
You are demonstrating what you've observed with the compilers you have.
Both are correct but they don't contradict each other.

The Standard does not mandate either behaviour. It should be reasonably
apparent that if somebody takes the address of a function, the body has to
exist somewhere otherwise what would the address point to? However, the
act of putting a copy of the function body with all necessary adjustments
into the code instead of a call to that function (known as "inlining") is
totally up to the compiler. It doesn't have to do it even if you use the
'inline' keyword.

Between two extremes: inlining all [static] calls to that function and
also providing a body elsewhere if the address is taken *and* not inlining
the function at all, is where the behaviour of a compliant compiler lies.
You should see by now that there is nothing to argue about.

V

Relevant Pages

  • 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)
  • Re: [2.6 patch] kernel/sched*: optimize inlining
    ... useful explanations, and in the case of a lack of explanations no ... That one simply says that previously every inline was force-inlined, ... OK, I know that it's not "chic" to argue about inlining stuff, ... As long as compiler intelligence in the realms of inlining seems ...
    (Linux-Kernel)
  • Re: RAD Studio Roadmap Updated
    ... Strict private and strict protected provide a means for the compiler ... It will comply according to the specification (of the inline ... the exposure of the implementation details is CRITICAL ...
    (borland.public.delphi.non-technical)
  • Re: [discuss] [2.6 patch] include/asm-x86_64 "extern inline" -> "static inline&quo
    ... But shouldn't the compiler that compiles Linux be C99 compliant? ... > if the inlining didn't work for some reason because if we say ... > inline we mean inline. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: OT: C++ overloading operators
    ... way before complex numbers were part of the STL. ... I used the INLINE directive for these trivial functions. ... A compiler can not do inlining without access to the source code. ...
    (comp.dsp)