[Development] To "inline" or not (Was " Mutex future directions")

[Thiago Macieira]

On terça-feira, 22 de maio de 2012 07.08.34, Atlant Schmidt wrote:
>   But in fact, isn't this much ado about nothing? If I
>   understand current compiler technology, when one declares
>   a function "inline", that's nothing more than a hint to
>   the compiler. (At least at high optimization settings),
>   the compiler can choose to ignore you and compile your
>   function as an ordinary out-of-line function. It can also
>   chose to elevate any ordinary function to inline if it
>   chooses. (Isn't "tail-folding" a common example of this?)

Hello Atlant

You're right in principle. The "inline" marker is just a hint to the compiler 
and it can freely choose to ignore it. Moreover, every function declared in 
the body of a class is also automatically "inline".

However, for us there is a "gotcha" that is important:

The inline marker has also an ABI effect. With GCC and the IA-64 ABI, an inline 
function is usually hidden, so that different copies of its out-of-line bodies 
are not merged. The compiler will emit a copy of the inline function in every 
.o that it needs to, instead of calling a copy provided from an external 
library. MSVC has a different behaviour here.

If you read the Binary compatibility guide, it says that it's ok to change an 
inline function or de-inline it, provided that it's also ok for the old code 
to remain. If the function was inlined, then the old code was inserted into 
the application code and we can't change it. And with GCC, even if it wasn't 
inlined, the code was *still* inserted into the application code.

So what matters to us is not the fact that the function is marked inline or 
not. The problem is that the effects of such a function would be in the 
application code, with the consequences that they can have.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120522/61e8b719/attachment.sig>