L'inlining, c'est le remplacement d'un appel de fonction par une copie de son corps :

Les avantages sont nombreux, les surcoûts de l'appel sont évités : les instructions call et return, la sauvegardes des registres, le passage de paramètres et l'ajustement de la pile n'ont plus lieu d'être. De plus, le compilateur peut appliquer plus d'optimisations en utilisant l'analyse de flot de données, par exemple la propagation de constantes est plus efficace, et la nouvelle région plus grande possède probablement plus de parallélisme d'instructions. Malheureusement, un inlining excessif peut conduire à une dégradation des performances, la forte expansion du code constitue l'envers de la médaille : si elle n'est pas contrôlée la dégradation des performances de la hiérarchie mémoire risque de contrebalancer les gains espérés : le taux de défauts de caches instructions risque d'augmenter. De plus, un trop grand nombre de paramètres et de variables locales de la fonction à inliner peut diminuer l'efficacité du compilateur dans l'analyse de flot, augmenter la pression sur les registres et introduire du spill code.

Pour ces raisons, l'inlining doit être contrôlé, le choix de quelles fonctions inliner est complexe. Il y a deux façons d'aborder le problème :

• inliner seulement si cela rapporte c'est-à-dire maximiser les bénéfices (ou maîtriser les effets de bords)
• inliner seulement si cela rapporte tout en respectant une borne supérieure à la taille de code c'est-a-dire maximiser les bénéfices et minimiser le coût (maîtriser les effets de bords et contrôler l'expansion de la taille du code)

La première approche consiste à maîtriser le gain apporté par l'inlining.

La deuxième approche est au moins aussi difficile que le problème du sac à dos qui est NP-complet. Cependant, plusieurs algorithmes d'approximation du problème du sac à dos sont connus pour être à une borne fixe de la solution optimale et pour être très efficaces en pratique. Un algorithme connu est l'algorithme glouton consistant à choisir les objets (ici les fonctions) dans l'ordre décroissant du ratio bénéfice/coût, c'est-à-dire le gain supposé divisé par le surcoût (la taille). Cet algorithme est utilisé dans de nombreuses expériences Arnold, McFarling et conduit à de bons résultats.

McFarling présente en plus un modèle précis pour déterminer si une procédure doit être inlinée. Ce modèle calcule le nombre de miss de cache introduit par l'inlining d'une fonction, si ce nombre est inférieur au gain espéré, la fonction est inlinée. Le modèle utilise un profil pour connaître la fréquence d'exécution des blocs de base et en déduire la taille effective du code exécuté, à partir de ces valeurs le modèle calcule pour chaque boucle du code le nombre de miss supplémentaires découlant de l'inlining. Le gain correspond au coût d'un appel multiplié par son nombre d'appels dynamiques, donné aussi par le profil.

Pour en savoir plus McFarling, Arnold