Talk:Inline expansion

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Confusion of concepts[edit]

This article fundamentally confuses the compiler optimization of inlining functions and the inline function as a language feature. In particular, the latter does not occur in functional languages, although the optimization is certainly done, and the macros vs. inline function debate is irrelevent to the former. These should ideally be separated into two crosslinking articles (say Inline function and this one). Derrick Coetzee 20:04, 25 Oct 2004 (UTC)

I don't think it is a confusion. What inline keyword does is it makes a suggestion to the compiler to inline functions. -- Taku 20:52, Oct 25, 2004 (UTC)
Obviously, but you can certainly have inlining without having inline functions (gcc will inline C functions in C90 with the appropriate flags, for example, and functional language compilers inline aggressively, although functional languages don't have inline functions.) Also, macros are effectively a source-level method for inlining functions, but on the other hand macros are not inline functions, the language feature. If not separate articles, the distinction should at least be clearly drawn. Derrick Coetzee 21:41, 25 Oct 2004 (UTC)
I think I am not getting what you mean by inlining functions as a language feature and inlining as not a language feature. My understanding of inling functions is simple as this article puts it: expand the implementation code for functions at each callsite instead of making function calls. In other words, it doesn't matter if it is realized as a language feature or is done by compilers. Functions can be expanded by setting the inline flag at the declaration of the function or passing an option to the compiler. The complications like expansion of recursive functions occur either way you use. In functional languages, you don't usually put inline flags at source code level because compilers try to inline functions anyway.
The mention of macros is not because it is the way to inline functions but because it is often contrasted with in-line expansion. I don't think the current article gives an impression that macros are line functions.
I am afraid I am not understanding you correctly. One option would be, only if you don't mind, you can go ahead separating articles and that may help me understand what you mean by the distinction. -- Taku 02:16, Oct 26, 2004 (UTC)

I went ahead and made this bold change. If you're still confused please drop me a note. I think this worked out pretty well. Derrick Coetzee 03:16, 26 Oct 2004 (UTC)

First of all, I like this new in-line expansion article; it says the obvious, how and why it is done and problems. But I still have a problem with inline function. Maybe we should make a distinction between manual inlining and automatic inlining (this is how I understand the distinction you mentioned first above). Yet the distinction is not necessarily clear-cut. As we know, the inline quantifier (is that what it is called?) in C++ makes only suggestion that functions could be inlined. That is, whether or not to inline is up to the compiler in the end. It is a language feature that aids the compiler optimization not something fudamentally different. Also, I still believe comparing this with macros makes sense. After all, the example given in the article could be done using macros and it is natural that readers ask "why do you define functions using macros instead of inling functions?"
Maybe you want this article to feel more like a section in the compiler construction text. Because in such a case, it is necessary to leave out language support or comparison with other language features. I don't know. I am just gussing.
Finally, if you think it is better to clarify my questions in actual articles, then go ahead and tell me that now the article addresses the questions or confusions I throw here. I am just saying I don't mind you keep editing the articles. -- Taku 15:41, Oct 26, 2004 (UTC)
The distinction is a little bit finer than just automatic versus manual selection. Although in-line functions are a mechanism for manual selection of functions to inline, in-line expansion is not an automatic selection method. Instead, it describes the actual process of inserting the body of the function in place of the call site, which takes place regardless of which method of selection is used. If there's any way you think this could be further clarified, please suggest it or go ahead and edit. Derrick Coetzee 17:43, 26 Oct 2004 (UTC)

in-line vs. inline[edit]

Can we decide on which form is preferrable? I think "inline" is more common. I think inline function, in-line expansion, and similar articles should be moved / fixed to refer to one form rather than intermixing them. Neilc 05:30, 1 May 2005 (UTC)

This is something I thought about. I used "in-line" because this was what was originally used at the time the concept was invented, and then inline was a sort of lazy abbreviation, but it seems like since then "inline" has become dominant, perhaps due to C++. The Google test strongly favours your spelling. I'll move it. Deco 17:30, 2 May 2005 (UTC)

Problems with inlining[edit]

"The added variables from the inlined procedure may consume additional registers, and in an area where register pressure is already high this may force spilling, which causes additional RAM accesses."

I think this statement should be removed or detailed, because a call to the non-inlined function would have the same issues regarding register allocation. A compiler that would get things worse would certainly be a very bad compiler, in my opinion. And inlining often reduce the number of variables used, either by dead code reduction and constant propagation, or by the added liberties in code transformations (e.g. some temporary result in the called function could be computed earlier in the calling function, at a time where more registers are available, although it might be a rare case). Clément Pillias (talk) 21:11, 17 August 2009 (UTC)

done Striepan (talk) 08:19, 7 April 2014 (UTC)