Thread: how to make sure g++ will not inline this?

Thanks a lot, you finally gave me, what I had been asking for.

Actually, matsp gave you several suggestions in post #5 ("The don't inline this way is to put the function in a different source file. Or call it through a function pointer. Or use some compiler option to say "don't inline".") and I elaborated on his last suggestion in post #9, but apparently you did not read the documentation I linked to.

Originally Posted by manav

Mats: Yeah, but this holds only if the function is called just once or may be twice or even thrice, may be!
Inline the function will always save a few instructions, like saving registers, getting parameters from stack, clearing stack etc.
But I think inline will be useless if the function happens to be called more than once!

It doesn't make much difference what the data type is - a double passed will be (fld, fst) inlined, and (sub sp, fld, fst, call, fld, fst, ret, add sp) as a direct call - so it's still a 5 instructions EXTRA for the call compared to the inlined version.

--
Mats

Originally Posted by manav

laserlight: I would read that later, since i thought you were giving me information regarding optimizations. Thanks.

Inlining _IS_ an optimization - it will reduce the overhead of calling the function by stuffing it inside the code.

Mats: You are a programming master! How the hell you know everything?

I wish I _could_ know EVERYTHING. I don't think ANY person knows EVERYTHING about programming, although I know (of) a few people who know a huge amount.

--
Mats

Originally Posted by manav

Why are you a Kernel Hacker?
Is kernel hacking fun? What exactly does it mean? Can you (or have done already) hack Vista also?

I use the term Hacker in it's original meaning - someone who understands and works inside the kernel of the OS (same meaning as for example Linus Torvalds would be considered a Kernel Hacker). I have worked on Windows graphics drivers, which are kernel drivers. I have worked on the Xen virtualization project, which is "super-kernel" (as in, manage multiple OS kernels running concurrently in the same machine - so you can have Windows and Linux running at exactly the same time on separate cores, or sharing the same core just like applications do inside Windows or Linux).

Edit: And yes, working on kernel code _IS_ fun - in the same way as riding a motorbike is more fun than driving a car - there's a bit more danger, but when you do it right, it's so much more rewarding.

--
Mats

Don't use -fno-default-inline. Just use -Os, and let the compiler handle this stuff. Really. -Os means optimize for code size, so the compiler will not use optimizations that increase performance at the cost of code size. This includes the inlining heuristics - at -Os, newer GCCs will only make the early-inlining pass, the one that inlines functions smaller than the call overhead. (Older GCCs - pre 4.1, I think - don't have an early-inlining pass, but the effect is still similar, I think.)

Originally Posted by CornedBee

Don't use -fno-default-inline. Just use -Os, and let the compiler handle this stuff. Really. -Os means optimize for code size, so the compiler will not use optimizations that increase performance at the cost of code size. This includes the inlining heuristics - at -Os, newer GCCs will only make the early-inlining pass, the one that inlines functions smaller than the call overhead. (Older GCCs - pre 4.1, I think - don't have an early-inlining pass, but the effect is still similar, I think.)

This obviously depends on what you want to achieve. -Os produces the smallest possible code, which may well inline a fairly large function if it's only called once. -fno-default-inline does

Do not make member functions inline by default merely because they are defined inside the class scope (C++ only). Otherwise, when you specify -O, member functions defined inside class scope are compiled inline by default; i.e., you don't need to add `inline' in front of the member function name.

--
Mats

Yes, indeed. Of course, making the smallest possible code is a sensible goal. Not inlining functions because you don't like inlining is not.

Originally Posted by CornedBee

Yes, indeed. Of course, making the smallest possible code is a sensible goal. Not inlining functions because you don't like inlining is not.

Agreed - there is one exception: When debugging optimized code [where the non-optimized code isn't showing the problem for some reason], and you want to set a breakpoint in some small function - the inliner will potentially inline this, which means that the breakpoint is non-functional.

--
Mats

Depends on how well the debugger copes with compiler transformations, and how well the compiler documents them. In optimized code, there's more things to worry about, like split statements, coalesced statements, statements completely computed at compile time, and so on.

Or you have screwed-up behaviour even with debug builds. For example, if you set a breakpoint to a code line in gdb, and that code line is in a template implementation, the breakpoint is set for one of the instantiations, and you have neither clue nor control over which one that is.

Most modern compilers (such as gcc and MS VC++) in default settings completely ignore "inline" as a keyword when it comes to what to inline and what to not inline. I know MSVC has a switch to say "inline by inline keyword only", but it's not the default setting.

However, if you put functions in a header file, they should be marked static, or part of a class.

--
Mats