4

How can you tell what will or what won't be made inline by the compiler?

Sometimes I have been told that some minor optimisations are pointless because the compiler will inline certain calls or calculations, other times similar optimisations seem to be recommended.

What are the rules that allow us to know when we do or don't need to optimise these things?

Dollarslice
  • 9,917
  • 22
  • 59
  • 87
  • You can't in general (though you can check if a given version with given flags inlines it in a particular revision of your code), but you can be pretty certain that if it's worth it and possible, the compiler will do it. –  Nov 25 '11 at 15:45
  • well I suppose in that case, how can you tell if it's worth it and possible? – Dollarslice Nov 25 '11 at 15:46
  • 2
    For possible, common sense and programming knowledge should be sufficent ;) As for worth it, the point is that the compiler decides that, and it can frequently decide it better than you (*especially* if you're making uninformed guesses, which is sadly rather common). –  Nov 25 '11 at 15:48
  • Slightly off-topic yet i reckon it's important to realize that this ' optimizations with inline ' are (generally) not a deal-breaking matter. I dareclaim that optimizing on higher level is far more important for any project larger than 500 lines than to worry about whether or not a function / method should or should not be inlined. Not to mention that most compilers are better at deciding whether or not to inline than you (or pretty much anyone else :)). Just a thought. – ScarletAmaranth Nov 25 '11 at 16:16
  • @SirYakalot: to check if it's worth optimizing, you will need a profiler (Callgrind for example). It will identify the hot spots in your application. There is more than pure CPU instructions to optimizing, cache miss, cache eviction, memory / IO bandwith. Many different costs, nigh impossible to assess them by just looking at the code. – Matthieu M. Nov 25 '11 at 18:52

9 Answers9

2

The only sure way to see if a something is inlined is to look at the assembly.

Whether or not something is inlined is completely compiler dependent - as the compiler has the final decision on whether to inline something.

Premature optimization aside: If it really matters (or if you're just curious) you can use compiler-specific pragmas to force inlining/no inlining on a function and then profile appropriately to see if you can make better decisions than the compiler.

Nevertheless there are some cases where you can be sure that a function cannot be inlined:

  • Virtually called functions where the type cannot be determined at compile time.
  • Recursive functions can never by fully inlined unless the maximum depth can be statically determined.
Mysticial
  • 464,885
  • 45
  • 335
  • 332
1

This might seem a little tangential, but I think it's important.

What are the rules that allow us to know when we do or don't need to optimise these things?

I would say that there are two rules that come in to play before any others W.R.T. this specific question:

  1. It probably doesn't matter. Unless you have profiled your code in a Release build and proved that the overhead associated with a function call is a major bottleneck in your code, you are better off forgetting about the performance implications of inlineing code.

  2. You have little or no control over what the compiler will an will not inline. inline can be ignored by the compiler if it sees fit to do so. Some things are impossible to inline. Some platforms provide language extensions along the lines of force_inline but even these can be ignored.

John Dibling
  • 99,718
  • 31
  • 186
  • 324
0

There are no solid rules. There are even some tests to test your assumptions about optimization.

Sjoerd
  • 74,049
  • 16
  • 131
  • 175
0
How can you tell what will or what won't be made inline by the compiler?

You cant :) forexample if you use the inline keyword, its a mere hint and no compiler is obliged to respect it. However if you need crazy optimisations it seems you may need to code at a lower level than c/c++ and use assembly calls

Dr Deo
  • 4,650
  • 11
  • 43
  • 73
0

Have you looked on SO already?

For example:

Does GCC inline C++ functions without the 'inline' keyword?

Why not mark everything inline?

The question your asking is very general - because it depends on things like which compiler, let alone which version. It sounds like what you were doing was premature optimization - you should be profiling your code and finding areas that are slowing it down. This sort of renders the "is this going to be inlined?" question moot, because you'll be looking at the after effect of the compiler, inlining and other optimizations included.

Community
  • 1
  • 1
Doug Moscrop
  • 4,479
  • 3
  • 26
  • 46
  • 1
    um, I wasn't doing anything actually. Just wondering what the answer to this question was. and I know the answer to your two linked questions, mine is asking something very different. – Dollarslice Nov 25 '11 at 15:54
0

There is no way to tell for sure, for details why and when inlining is good practice I recommend reading this C++ FAQ

Alex
  • 5,240
  • 1
  • 31
  • 38
0

You cannot know what the compiler is going to inline during the optimization phase: you should know by heart the heuristics of a precise compiler. You can specify what you would like to inline, though.

ziu
  • 2,634
  • 2
  • 24
  • 39
0

Microsoft's Compiler has for a long time had the /Ob optimization flag which forces it to inline all and only functions explicitly declared inline. This is non-standard, and by default, it behaves according to the standard, which is to take the keyword as nothing more than a hint. The Intel Parallel Studio compiler behaves similarly.

Josh Greifer
  • 3,151
  • 24
  • 25
0

How can you tell what will or what won't be made inline by the compiler?

You cannot, in general.

You may want to read the Inline Redux article by Herb Sutter. It exposes a number of technologies to explain when inlining may happen, knowing that the latter it happens... the more information you have.

For example, in a JIT environment, you could look at a loop, realize the whole of its body is executed on a single object which appears to be frequently of type Foo, specialize the whole body for Foo, which allows full inlining of virtual methods, and now check at the top of the loop if the object is a Foo and if so switch to the fully inlined body version instead of the generic one with virtual calls.

So what can be inlined ? It depends when...

In general C++ compilers feature:

  • Compile time inlining (historical)
  • Link time inlining (part of the so called LTO optimization package)

This means that they can only base their optimizations on static (known at compile-time) information.

At compile-time, this means that if the static type a virtual call might be devirtualized (first step of inlining: guessing the actual function called ;) ). It means that any function which definition is visible can also be inlined.

At link-time for a library, you basically expose new function definitions which allows to inline a few calls.

At link-time for an executable, WPA (Whole Program Analysis) can kick off to add some devirtualization by realizing that some classes are never derived from, and thus can be considered final as far as this executable is concerned. Neither GCC nor LLVM (and I doubt VC++ can) may perform this optimization though because they do not have a byte code that keeps class hierarchies around.

And compilers could, if they wished, dump the intermediate representation they have (bytecode in a way) and wait for the installation to inline OS-specific calls. Though I know of none (for C++) that do this.

Runtime changes is quite tricky in C++ because memory (for example function addresses) is accessible to the programmer so it would be difficult to make only safe transformations...

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722