compiler refues to inline my function

[sockman]

I have the following simple function:

inline int Gain(int in, int mq)
{
   return (in * mq) >> 9;
}

This function is called frequently in my program (millions of times every minute). I noticed while doing some optimisations today that Visual Studio is not actually inlining the function. No real surprises here since VS ignores most inline recommendations and does what it wants.

The issue I have is that making this function inline makes a huge difference - I get approx a 50% performance gain if I just substitute my calls to Gain() with this code directly.

I have tried using __forceinline. No help - VS seems to ignore this too.

I have tried switching on "Maximize Speed" (/O2). No difference.

I have tried switching on "Favor Fast Code" (/Ot). Executable increased in size by 10% and got slower by about 15%. Obviously that's no good.

Can anyone shed some light on why the compiler refuses to inline this function?

BJW

[Lindley]

Make sure it's "above" most of the places where it's used. I don't know if that makes a difference, but it's conceivable it might.

If all else fails, I suppose you could define it as a macro rather than a function.

[cilu]

The problem with inline is that the compiler has the last word. The keyword inline only acts as a suggestion, but it's the compiler that decides whether to inline or not.

__forceinline is a stronger recommendation, but still no guarantee.

The compiler treats the inline expansion options and keywords as suggestions. There is no guarantee that functions will be inlined. You cannot force the compiler to inline a particular function, even with the __forceinline keyword.

As Lindley said, if nothing works, use a macro.

[sockman]

Thanks for the responses.

@lindley: Good idea, I'll try it on Monday when I get back to work.

@cilu: I know the inline is just a suggestion to the compiler - seems like most of the time the compiler barely even considers it. What irritates me is that it seems like a pretty obvious candidate for inlining and now I'm left with no elegant solution. It also makes me wonder where else in the library we might have this problem.

[olivthill2]

It's a nonsense to use a function for just one line. You are wasting a lot of precious CPU time passing arguments.
Suppose you want to perform an addition, you would not write

inline int Addition(int a, int b)
{
   return (a + b);
}
...
result = Addition(2,2);

Instead you would write:

 result = 2 + 2

It's the same thing here. Don't call your (loosing) Gain function, just write:

 result = (in * mq) >> 9;

[cilu]

Well, the advantage of having inline functions is that the code is in a single place, and not replicated. If you need to make a change, it's only one, not several.

[sockman]

@olivthill:
Maybe you need to review some basic text books? This loosing function as you call it has very specific signal processing purposes and is called from hundreds of places in my code. This means if I need to change it then I can change it in one place rather than hundreds. There is absolutely nothing wrong with having a function which does one thing. The example you provide is completely irrelevant and out of context.

[Martin O]

There is absolutely nothing wrong with having a function which does one thing.

I agree. It can also be used to make code more 'self documenting'.

[OReubens]

There's absoluately no reason that particular function would fall under the rules of not getting inlined. So... My first instinct would point to the fact you're not telling the compiler it's allowed to use inlines.
Check the "Inline Function Expansion" setting in the C/C++ optimisation settings for your sources. (needs to be /Ob1 or /Ob2)

Note that inlining will not work if you're calling the function via a function pointer.

Make sure that not one of your included headears is turning off inlining and not restoring it to it's default setting. (#pragma inline_depth( 0 ) )


If either of the parameters is a volatile, it's likely causing the function to end up as a call. I can't particularly say why it would have to be that way, but it's something I noticed happening before.

[Syslock]

Try putting these lines around it:

#pragma optimize( "", off )
__forceinline int Gain(int in, int mq)
{
   return (in * mq) >> 9;
}
#pragma optimize( "", on )

And replace inline with __forceinline for good measure.

[VladimirF]

I agree with OReubens, this function should get inlined (if there is nothing funny going on elsewhere in your code).
This code doesn't suggest inlining to Visual Studio compiler:

int Gain(int in, int mq)
{
   return (in * mq) >> 9;
}

but sure enough it gets inlined anyway:

int main(int argc, char** )
{
	return Gain(argc+42, argc+7);
00401000  mov         ecx,dword ptr [esp+4] 
00401004  lea         eax,[ecx+2Ah] 
00401007  add         ecx,7 
0040100A  imul        eax,ecx 
0040100D  sar         eax,9 
}
00401010  ret