inline question

[toton]

Hi,
As inline is not mandetory, it depends on compiler to inline certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but is
it free to choose a non inline function to inline it?
I have some simple one line get function, and index operators which I
want to get inlined. But due to some problem (like I have some circular
dependency, thus use forward declaration, and hence not possible to
have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining? If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.
Those get functions return certain kind of container , which in turns
a class use to return a begin & end iterator for the container. ( i.e a
view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).

 

[Paolo]

toton ha scritto:

Hi,
As inline is not mandetory, it depends on compiler to inline certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but is
it free to choose a non inline function to inline it?
I have some simple one line get function, and index operators which I
want to get inlined. But due to some problem (like I have some circular
dependency, thus use forward declaration, and hence not possible to
have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining? If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.
Those get functions return certain kind of container , which in turns
a class use to return a begin & end iterator for the container. ( i.e a
view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).

I think that most compilers choose if "inline" a function by itself,
they don't care much about the inline keyword. They often don't
"inline" a function that is declared inline or they do so even if you
didn't declare it inline.

 

[Phlip]

I think that most compilers choose if "inline" a function by itself,
they don't care much about the inline keyword. They often don't
"inline" a function that is declared inline or they do so even if you
didn't declare it inline.

The rule here is called "as if".

The C++ Standard reputedly describes a C++ compiler in terms of creating
specific kinds of opcodes. But compilers are free to create any kind of
alternate opcodes so long as the results perform "as if" the compiler had
created the specified opcodes.

So a compiler might inline functions in ways that optimize the calling code,
regardless which called functions are declared inline.

 

[Bo Persson]

Hi,
As inline is not mandetory, it depends on compiler to inline
certain
function (or using switch like fior GCC), my question is there any
scope for inlining when it is not declared as inline function?
i.e compiler may choose not to inline certain inline function, but
is
it free to choose a non inline function to inline it?

Yes. The compiler can do whatever it wants, as long as the visible
effect is the same. How would you detect whether a function is inlined
or pot?

I have some simple one line get function, and index operators which
I
want to get inlined. But due to some problem (like I have some
circular dependency, thus use forward declaration, and hence not
possible to have some get function implemented in header).

Secondly, If i build a library with the getter function in the cpp
file, rather than header, (and so it is not inlined) , does it mean
that the scope for optimization is lost for inlining?

That doesn't stop some compilers from inlining anyway.

If it is even
have a function call, how costly will it be (comparing to inlined
version) , given the fact it is a getter and thus do not have any
parameter list.

A function call will cost some more. Does it matter?

If a one line getter takes twice as long, will anyone notice?

Those get functions return certain kind of container , which in
turns
a class use to return a begin & end iterator for the container. (
i.e
a view class construct a pair of iterator with the help of original
container whose reference it holds, for certain range, and return).

Here the answer is of course the boring "It depends".

There is no general answer for a kind of container with some iterator,
where some functions might get inlined (or not). To get the true
result, you have to try it out and measure if it is fast enough. Most
often it is.


Bo Persson

 

[Ivan Vecerina]

: Hi,
: As inline is not mandetory, it depends on compiler to inline certain
: function (or using switch like fior GCC), my question is there any
: scope for inlining when it is not declared as inline function?
: i.e compiler may choose not to inline certain inline function, but is
: it free to choose a non inline function to inline it?
Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.
Some current compilers will automatically inline some functions
in optimized builds - or decide to refuse inlining some functions
(e.g. when compiling in "optimize for size" mode).

: Secondly, If i build a library with the getter function in the cpp
: file, rather than header, (and so it is not inlined) , does it mean
: that the scope for optimization is lost for inlining?
In most cases yes, probably, although not necessarily.
Several platforms today implement linker-time global program
optimizations, and might inline such functions as well.


hth --Ivan

 

[toton]

: Hi,
: As inline is not mandetory, it depends on compiler to inline certain
: function (or using switch like fior GCC), my question is there any
: scope for inlining when it is not declared as inline function?
: i.e compiler may choose not to inline certain inline function, but is
: it free to choose a non inline function to inline it?
Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.

So a bright future! I wish a quick death to keywords like register,
auto and inline. But at the same time it is better to have attributes
to guide compiler. @inline can be an attribute to guide compiler to
inline certain code. Because it is almost always true that human being
knows more about the program than compiler do. Thus a loop unrolling
behaviour may be needed for some particular loop which runs too
frequent (may be even a big loop), while a small loop which runs rarely
in runtime may not need that kind of attention! Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it

Some current compilers will automatically inline some functions
in optimized builds - or decide to refuse inlining some functions
(e.g. when compiling in "optimize for size" mode).

: Secondly, If i build a library with the getter function in the cpp
: file, rather than header, (and so it is not inlined) , does it mean
: that the scope for optimization is lost for inlining?
In most cases yes, probably, although not necessarily.
Several platforms today implement linker-time global program
optimizations, and might inline such functions as well.


hth --Ivan
--

The group is really nice!
Thanks for the reply.

 

[peter koch]

toton wrote:
[snip]

Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it

This is done today already.

 

[Steve Pope]

I have some simple one line get function, and index operators
which I want to get inlined. But due to some problem (like I have
some circular dependency, thus use forward declaration, and hence
not possible to have some get function implemented in header).

If you use a macro instead of a function, then it will definitely get
inlined. Just be careful.

BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.

Steve

 

[Phlip]

BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.

There is no compiling difference between these two foo() functions:

struct A { void foo() {} };
struct B { inline void foo() {} };

Both allow foo()'s body to appear in more than one translation unit. Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.

 

[Jens Theisen]

Yes.
There is hope (within few years?) that the 'inline' keyword will be
just as redundant as 'register' is today.

inline is part of the ODR. I can't see how inline can be made
redundant without changing it.

Regards,

Jens

 

[Steve Pope]

Steve Pope wrote:

There is no compiling difference between these two foo() functions:

struct A { void foo() {} };
struct B { inline void foo() {} };

Both allow foo()'s body to appear in more than one translation unit. Neither
will force the compiler to in-line foo's opcodes, and both offer a strong
suggestion to in-line the opcodes.

Why do you say that the first form offers a "strong suggestion"
to inline the opcode?

Steve

 

[Phlip]

inline is part of the ODR. I can't see how inline can be made
redundant without changing it.

'Register' and 'auto' no longer have a meaning. 'inline' does.

My hope is the C languages in general will graduate from their broken linker
model, where we must define everything twice just so an O file doesn't need
to contain real linking information.

 

[Steve Pope]

Jens Theisen wrote:

'Register' and 'auto' no longer have a meaning. 'inline' does.

My hope is the C languages in general will graduate from their broken linker
model, where we must define everything twice just so an O file doesn't need
to contain real linking information.

I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.

This was not so bad in C, since you would typically declare them all at
the beginning of the function's block, and the compiler would place
them in registers until it ran out. In C++, with vairables declared
willy-nilly throughout the function, the register keyword is more
useful.

Steve

 

[Phlip]

Why do you say that the first form offers a "strong suggestion"
to inline the opcode?

[Because C languages don't store very much data in a linker, so] at compile
time, a compiler sees many functions in each translation unit. It must
decide which to inline, and must re-decide once per translation unit. The
functions with external linkage, it _generally_ should not inline, because
the external callers must find an address to jump to, and expressing the
function twice (once inline and again out-of-line) is _generally_
inefficient. (The compiler might still do it.) And the compiler _generally_
cannot share optimization data between translation units. (Sometimes it can;
historically it couldn't!)

Both A::foo and B::foo don't have external linkage. Both can appear in more
than one translation unit, if their definitions are exactly the same. (And
linkers generally don't check that they are the same, at link time!)

Hence, both A::foo and B::foo have told the compiler all it is capable of
knowing about whether to inline either method, and both tell it the same
amount of information. No external linkage == yes the odds are low that
someone will take the address of either foo, or generally do something
requiring the compiler to express an out-of-line version of it.

In general, the idea that 'inline' forms any kind of command, to a compiler,
to inline a function, is a big myth.

 

[Phlip]

I have always liked "register" because it is not in general possible
from textual analysis to determine which of the auto variables
in a function are used most frequently.

Are you directly aware of any compiler that actually obeys that keyword in
any way?

I have not studied this topic, yet I grew the suspicion that they all
discard it these days.

Also, registering the variable that's used "most frequently" might actually
not improve performance!

 

[Phlip]

There is no compiling difference between these two foo() functions:
And I suspect all this analysis is simply orthogonal to the Standard's
commandment that A::foo is treated as if decorated with an 'inline', because
it is fully defined inside A's definition...

 

[Steve Pope]

Steve Pope wrote:

[Because C languages don't store very much data in a linker, so] at compile
time, a compiler sees many functions in each translation unit. It must
decide which to inline, and must re-decide once per translation unit. The
functions with external linkage, it _generally_ should not inline, because
the external callers must find an address to jump to, and expressing the
function twice (once inline and again out-of-line) is _generally_
inefficient. (The compiler might still do it.)

Good explanation. I'll agree that, without lots of monkey tricks
in the linker, functions defined in one translation unit are not
going to be easily inlined when called from another translation unit.

On the other hand, just to nitpick, if the function definition
and the caller *are* in the same translation unit, whether that
function is defined within a class declaration, or outside of
any class declaration, does not affect the ease with which it
could be inlined.

Steve

 

[Steve Pope]

Steve Pope wrote:

Are you directly aware of any compiler that actually obeys
that keyword in any way?

Yes, certainly with gcc (as of a few years ago, and don't ask
me which version) I have obtained speedups by using "register"
even at -O4 or -O5. Particularly when register is applied to
a pointer that subsequently has the ++ or -- operator applied.

Steve

 

[toton]

toton wrote:
[snip]

Or may be someday
compiler will compile the program, ask user to run a few standard run,
collect the stats and reoptimize the program based on that. A SemiJIT
or CachedJIT, whatever you call it

This is done today already.

Which compiler do it for C++? I only know IBM Java VM cache the Jitted
code from first run of the Java program, for subsiquent runs. Not aware
of any other compiler (C++ or any other language), which ask user or
programmer for a few "typical run" of the program and optimize the
code. This is something like optimizing the code statically, before
actual run, based on standard run for specific processor architecture.
Interested to hear about such AOT compilers or some reference to them.

 

[toton]

If you use a macro instead of a function, then it will definitely get
inlined. Just be careful.

Macros are evil. I will never use them except some very simple cases,
even when I am very carefull.
http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.5

BTW, implementing a function in a header is not the same thing
as inlining it. All that does is repeat the text of the function in
each translation unit. While it is popular to refer to functions
implemented in a header as "inlined", this is a misnomer.

I hadn't said that. What I had said is that inlined functions need to
be in header (not translation unit) , may be at the place of
declaration, or may be seperately after declaration. If the whole
header file has forward declaration of cetrain class, due to circular
dependency, One can not write inline function which use the definition.