I need to make the compiler to not inline an inlined function.
eg:
I have an inline function A.
I have a function B that calls A.
In B, A is inlined and this is perfect.
Now I have a function C that calls A many times.
In C, A is inlined, and it is not good.
Is it possible to tell the compiler to not inline A when it is called from C ?
--edit--
The first Idea is to create the function __declspec(noinline) A1 (that simply calls A) and call A1 instead of A in C.
But I wondering if there is a more elegant solution ?
note
I know that inline is only a suggestion, but in my program, I have some unlikely or error cases where the compiler inline functions but should not because in these cases I prefer function calls to reduce code size. I also noticed that the compiler is not always able to make the best choice (in the point of view of the developer)
In general, you cannot tell your compiler to inline or not inline a function. This is an internal optimization and even if you declare a function inline, the compiler may chose to not do so.
Some compilers allow you to control inlining to some extent. For instance, GCC has a function attribute noinline that prevents it from being inlined.
In your case, I'd try something like this:
inline void a() { ... }
void __attribute__((noinline)) wrap_a()
{ a(); }
void b() { a(); }
void c() { wrap_a(); }
Inlining is only a suggestion to compiler -- it is quite possible that the function won't be pasted in the second case. I would just trust the compiler and leave it as is.
I have found the following solution:
template <class F> ALWAYS_INLINE F NOINLINE( F f ) {
return f;
}
It seems that the compiler (MSVC at least) don't inline functions called like this:
NOINLINE(my_inline_function)();
I think it is similar to the "calling it through a function pointer" solution from Nick D
The most straight forward solution is to put the function code into a separate file.
Related
Why should i do something like this:
inline double square (double x) { return x*x;}
instead of
double square (double x) { return x*x;}
Is there a difference?
The former (using inline) allows you to put that function in a header file, where it can be included in multiple source files. Using inline makes the identifier in file scope, much like declaring it static. Without using inline, you would get a multiple symbol definition error from the linker.
Of course, this is in addition to the hint to the compiler that the function should be compiled inline into where it is used (avoiding a function call overhead). The compiler is not required to act upon the inline hint.
On a modern compiler there is likely not much difference. It may be inlined without the inline and it may not be inlined with the inline.
Yes there is a difference. https://isocpp.org/wiki/faq/inline-functions.
When you specify that a function is inline you are causing the compiler to put the code of the method in where ever it is being called.
void myfunc() {
square(2);
}
is identical to
void myfunc() {
2 * 2;
}
Calling a function is good for code clarity, but when that function is called the local state has to be pushed to the stack, a new local state is setup for the method, and when it is done the previous state needs to be popped. That is a lot of overhead.
Now if you up your optimization level, the compiler will make decisions like unrolling loops or inlining functions. The compiler is still free to ignore the inline statement.
From Wikipedia: Inline function is a function upon which the compiler has been requested to perform inline expansion. In other words, the programmer has requested that the compiler insert the complete body of the function in every place that the function is called, rather than generating code to call the function in the one place it is defined. Compilers are not obligated to respect this request.
http://en.wikipedia.org/wiki/Inline_function
inline works well with the concept of procedural abstraction:
inline double square (double x) { return x*x;}
int squareTwice(double x) {
double first = square(x);
double second = square(x);
return first * second;
}
The above is fundamentally similar to the following:
int squareTwice(double x) {
double first = x*x;
double second = x*x;
return first * second;
}
This happens because when the compiler inline-expands a function call, the function's code gets inserted into the caller's code stream; therefore, it may be easier to procedurally abstract the second example to the first example.
Procedural abstraction makes it possible to break up a routine into smaller subroutines that are much easier to read (although this can be a style choice).
The inline function, if the compiler complies, will include the inline function in the code in which it was called as if no function was called (as though you had put the logic in the calling function) and avoid the function call overhead.
If you've enabled full optimizations in your compiler and have classes setup like this:
class A
{
void Do_A_Stuff();
};
class B
{
A a;
void Do_B_Stuff() { a.Do_A_Stuff(); }
};
class C
{
B b;
void Do_C_Stuff() { b.Do_B_Stuff(); }
};
class D
{
C c;
void Do_D_Stuff() { c.Do_C_Stuff(); }
};
Is there ever a situation where calling Do_D_Stuff() would be slower than directly calling Do_A_Stuff()? Also, would this require the inline keyword on each wrapper 'chain' or, since it is only a suggestion, could the compiler decide to optimize this without the keyword?
I realize there is a lot of information about inlining available, but I could not find any information specifically about chaining many wrappers together.
Also, would this require the inline keyword on each wrapper 'chain' or, since it is only a suggestion, could the compiler decide to optimize this without the keyword?
Yes, the compiler could decide to optimize it anyway, and it could also decide not to optimize it even if you specified the inline keyword (possibly producing a warning if the appropriate compiler options are set) - notice, that member functions defined in a class definition are implicitly marked as inline.
In general, if inlining is possible, the compiler will decide whether to inline or not based on the body of the function being called. However, inlining may not be possible at all if the function is a virtual function, or if the definition of the function is not visible to the compiler.
Provided that the conditions for inlining are satisfied and that the compiler considers it appropriate, there is no technical problem in inlining over a chain of function calls.
As a minor remark, notice that the functions in your classes should be public, otherwise they won't be accessible to your wrappers.
The functions are defined inside the class definition, so the inline keyword is implicit in this case.
Let us say I have a function in my program and somewhere in my code, that function is called through a function pointer. What happens if the compiler happened to inline that function, or would the compiler realize that there is a function pointer assigned to that function and therefore avoid inlining it.
When a pointer to a function is taken, the compiler will generate an out-of-line body for the function. It is still possible to inline the function at other call sites.
Note that a function marked inline must have a definition available in all TUs which refer to it, and these definitions must be identical. Which means it's perfectly safe to inline the function at some call sites and keep it out-of-line at others.
Well, it will surely work. I don't see how inlining would prevent that. You just have some code that calls the function directly, and it might be inlined there, and you have some code which calls it through a function pointer, just as a regular function.
There's no reason that using a function pointer should prevent inlining. Inlining is done on a case-by-case basis and can exist alongside a usual function body. So a function can be inlined in one place, and called in another.
The compiler will, therefore, inline where it can and still produce a callable function for your function pointer.
Not only does the compiler inline "other calls of the function", but it may even inline calls through function pointers if it understands enough about which function is actually being used, something like this:
typedef void (*funcptr)();
void somefunc()
{
... do stuff here ...
}
void indirection(funcptr *f)
{
f();
}
void call_with_ptr()
{
funcptr f = somefunc();
for(int i = 0; i < 100; i++)
{
indirection(f);
}
}
I had code similar to this, and it inlined the indirection, and made the call to somefunc() a direct call without using the function pointer.
But of course, this assumes the compiler can figure out which function is called from the code - which is obvious in this case, but if there is runtime decisions involved, it may not do so.
Why should i do something like this:
inline double square (double x) { return x*x;}
instead of
double square (double x) { return x*x;}
Is there a difference?
The former (using inline) allows you to put that function in a header file, where it can be included in multiple source files. Using inline makes the identifier in file scope, much like declaring it static. Without using inline, you would get a multiple symbol definition error from the linker.
Of course, this is in addition to the hint to the compiler that the function should be compiled inline into where it is used (avoiding a function call overhead). The compiler is not required to act upon the inline hint.
On a modern compiler there is likely not much difference. It may be inlined without the inline and it may not be inlined with the inline.
Yes there is a difference. https://isocpp.org/wiki/faq/inline-functions.
When you specify that a function is inline you are causing the compiler to put the code of the method in where ever it is being called.
void myfunc() {
square(2);
}
is identical to
void myfunc() {
2 * 2;
}
Calling a function is good for code clarity, but when that function is called the local state has to be pushed to the stack, a new local state is setup for the method, and when it is done the previous state needs to be popped. That is a lot of overhead.
Now if you up your optimization level, the compiler will make decisions like unrolling loops or inlining functions. The compiler is still free to ignore the inline statement.
From Wikipedia: Inline function is a function upon which the compiler has been requested to perform inline expansion. In other words, the programmer has requested that the compiler insert the complete body of the function in every place that the function is called, rather than generating code to call the function in the one place it is defined. Compilers are not obligated to respect this request.
http://en.wikipedia.org/wiki/Inline_function
inline works well with the concept of procedural abstraction:
inline double square (double x) { return x*x;}
int squareTwice(double x) {
double first = square(x);
double second = square(x);
return first * second;
}
The above is fundamentally similar to the following:
int squareTwice(double x) {
double first = x*x;
double second = x*x;
return first * second;
}
This happens because when the compiler inline-expands a function call, the function's code gets inserted into the caller's code stream; therefore, it may be easier to procedurally abstract the second example to the first example.
Procedural abstraction makes it possible to break up a routine into smaller subroutines that are much easier to read (although this can be a style choice).
The inline function, if the compiler complies, will include the inline function in the code in which it was called as if no function was called (as though you had put the logic in the calling function) and avoid the function call overhead.
VC++ makes functions which are implemented within the class declaration inline functions.
If I declare a class Foo as follows, then are the CONSTRUCTOR and DESTRUCTOR inline functions?
class Foo
{
int* p;
public:
Foo() { p = new char[0x00100000]; }
~Foo() { delete [] p; }
};
{
Foo f;
(f);
}
Defining the body of the constructor INSIDE the class has the same effect as placing the function OUTSIDE the class with the "inline" keyword.
In both cases it's a hint to the compiler. An "inline" function doesn't necessarily mean the function will be inlined. That depends on the complexity of the function and other rules.
The short answer is yes. Any function can be declared inline, and putting the function body in the class definition is one way of doing that. You could also have done:
class Foo
{
int* p;
public:
Foo();
~Foo();
};
inline Foo::Foo()
{
p = new char[0x00100000];
}
inline Foo::~Foo()
{
delete [] p;
}
However, it's up to the compiler if it actually does inline the function. VC++ pretty much ignores your requests for inlining. It will only inline a function if it thinks it's a good idea. Recent versions of the compiler will also inline things that are in separate .obj files and not declared inline (e.g. from code in different .cpp files) if you use link time code generation.
You could use the __forceinline keyword to tell the compiler that you really really mean it when you say "inline this function", but it's usally not worth it. In many cases, the compiler really does know best.
Putting the function definition in the class body is equivalent to marking a function with the inline keyword. That means the function may or may not be inlined by the compiler. So I guess the best answer would be "maybe"?
To the same extent that we can make any other function inline, yes.
To inline or not is mostly decided by your compiler. Inline in the code only hints to the compiler.
One rule that you can count on is that virtual functions will never be inlined. If your base class has virtual constructor/destructor yours will probably never be inlined.