Re: Inline virtual call puzzling behaviour

[Michael Matz <matz at suse dot de>]

Hi,

On Sun, 7 Jul 2013, Thierry Lavoie wrote:

> int main(int argc, char** argv)
> {
>         A* ptr = 0;
>         if(argc == 1)
>                 ptr = new B();
>         else
>                 ptr = new A();
> 
>         ptr->blah();
> 
>         B().blah();
>         C().blah();
> }
> 
> The puzzling part is to find that the call for C().blah() is indeed 
> inlined and the ptr->blah() uses a VTable resolution, but the code for 
> B.blah() uses neither: the static adress is resolved but the code is not 
> inlined! (The same behaviour occurs if there would be a static-typed 
> pointer to an object of class B). I understand the compiler propagates 
> the types properly, but even after determining the correct type for the 
> object of type B, it only resolves the vtable reference (hence no call 
> *(%..x) ), but cannot perform the inlining.

It can, but decides to not do.  main is special and known to the compiler 
to be called only once, hence is itself cold, and GCC thinks inlining 
B::blah increases code size (of main).  Rename main to foo, or put the 
whole code of main into a loop with unknown bounds and you see B::blah 
inlined (as well as some other functions).  That C::blah is inlined in 
your example is a side-effect of that function being non-virtual, so some 
other transformations remove the 'this' argument, ultimately making gcc 
think inlining C::blah decreases code size of main (and hence it inlines 
even into that cold function).

> From a practical point of view, I understand this example does not 
> justify by itself the absolute need for inlining. However, I do have a 
> time-critical application that would get 25-30% increase in speed if I 
> could solve this issue.

Then the above testcase doesn't reflect the real issue you have.


Ciao,
Michael.