On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote:> > >> I know/hope that the proposal isn't for the inlinehint to be a >> synonym >> for "force inline", it would just raise the threshold to increase the >> likeliness that it would be inlined. The question is whether >> "something being c++ inline" in any way is really trustworthy, and if >> so, whether we should look at syntactic vs semantic inline. > > > FWIW, I've been involved in a couple of attempts by commercial > compilers to relegate "inline" to the same status as "register" -- an > obsolete hint ignored by the compiler -- and so far that always proved > to be unpractical because some critical calls that were previously > inlined were no longer being inlined after the change. (That's just > annecdotal, of course: LLVM may have gotten good enough to make it > practical. If that's the case, I still think it's too early to > write C > ++ code with that assumption.)It's actually the other way around. llvm has always ignored the "inline" keyword and now we are finding out we are missing some important cases. Obviously the only correct solution is to make the inliner smarter so it can identify cases which are profitable that's currently ignoring. No one is arguing against that. On the other hand, that is most definitely not a simple solution. So we need an intermediate step. The current plan is to make it behave a bit more like gcc (yeah I know it's not exactly where we want to go) so the "inline" keyword only impacts -O2 compilation. We should make conservative changes and then re-evaluate once we have more data. That means people who use llvm to compile C++ programs should definitely report any kind of performance changes once this change goes into effect. Evan> > Daveed > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, Aug 26, 2009 at 3:57 PM, Evan Cheng<evan.cheng at apple.com> wrote:> > On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote: > >> >> >>> I know/hope that the proposal isn't for the inlinehint to be a >>> synonym >>> for "force inline", it would just raise the threshold to increase the >>> likeliness that it would be inlined. The question is whether >>> "something being c++ inline" in any way is really trustworthy, and if >>> so, whether we should look at syntactic vs semantic inline. >> >> >> FWIW, I've been involved in a couple of attempts by commercial >> compilers to relegate "inline" to the same status as "register" -- an >> obsolete hint ignored by the compiler -- and so far that always proved >> to be unpractical because some critical calls that were previously >> inlined were no longer being inlined after the change. (That's just >> annecdotal, of course: LLVM may have gotten good enough to make it >> practical. If that's the case, I still think it's too early to >> write C >> ++ code with that assumption.) > > It's actually the other way around. llvm has always ignored the > "inline" keyword and now we are finding out we are missing some > important cases.It would help this discussion if you could post some examples. -Eli
On Aug 26, 2009, at 4:05 PM, Eli Friedman wrote:> On Wed, Aug 26, 2009 at 3:57 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> >> On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote: >> >>> >>> >>>> I know/hope that the proposal isn't for the inlinehint to be a >>>> synonym >>>> for "force inline", it would just raise the threshold to increase >>>> the >>>> likeliness that it would be inlined. The question is whether >>>> "something being c++ inline" in any way is really trustworthy, >>>> and if >>>> so, whether we should look at syntactic vs semantic inline. >>> >>> >>> FWIW, I've been involved in a couple of attempts by commercial >>> compilers to relegate "inline" to the same status as "register" -- >>> an >>> obsolete hint ignored by the compiler -- and so far that always >>> proved >>> to be unpractical because some critical calls that were previously >>> inlined were no longer being inlined after the change. (That's just >>> annecdotal, of course: LLVM may have gotten good enough to make it >>> practical. If that's the case, I still think it's too early to >>> write C >>> ++ code with that assumption.) >> >> It's actually the other way around. llvm has always ignored the >> "inline" keyword and now we are finding out we are missing some >> important cases. > > It would help this discussion if you could post some examples.We know for a fact WebKit suffered when we turned off gcc inliner: pr2353. Dale is looking at this. Unfortunately it's a huge code base, it has not been easy to extract out smaller test cases. It's all part of the investigation that's going on right now. Evan> > -Eli
On Aug 26, 2009, at 6:57 PM, Evan Cheng wrote:> > On Aug 26, 2009, at 2:31 PM, David Vandevoorde wrote: > >> >> >>> I know/hope that the proposal isn't for the inlinehint to be a >>> synonym >>> for "force inline", it would just raise the threshold to increase >>> the >>> likeliness that it would be inlined. The question is whether >>> "something being c++ inline" in any way is really trustworthy, and >>> if >>> so, whether we should look at syntactic vs semantic inline. >> >> >> FWIW, I've been involved in a couple of attempts by commercial >> compilers to relegate "inline" to the same status as "register" -- an >> obsolete hint ignored by the compiler -- and so far that always >> proved >> to be unpractical because some critical calls that were previously >> inlined were no longer being inlined after the change. (That's just >> annecdotal, of course: LLVM may have gotten good enough to make it >> practical. If that's the case, I still think it's too early to >> write C >> ++ code with that assumption.) > > It's actually the other way around. llvm has always ignored the > "inline" keyword and now we are finding out we are missing some > important cases.Okay. It's the "other way around" in terms of history, but it looks like the conclusion might be the same: Purely heuristics-based inlining hasn't been proven entirely competitive yet (for C++)? I read in your reply to Eli Friedman that there previously was another inliner (part of GCC) that presumably did take the C++ inline property into account? In at least two of the cases I was involved in, the scenario was similar: Really dumb "front end" inliners (that only inlined inline functions) ended up making a difference that couldn't be absorbed by improvements in the back end inliner (within the resource/schedule constraints of those subprojects).> Obviously the only correct solution is to make the inliner smarter so > it can identify cases which are profitable that's currently ignoring.Is that really obvious? It would be nice to have such a correct solution, but I'm not positive there exists one. (There may be just as there turned out to be for register allocators -- I'm just not sure.)> No one is arguing against that. On the other hand, that is most > definitely not a simple solution. So we need an intermediate step. > > The current plan is to make it behave a bit more like gcc (yeah I know > it's not exactly where we want to go) so the "inline" keyword only > impacts -O2 compilation. We should make conservative changes and then > re-evaluate once we have more data. That means people who use llvm to > compile C++ programs should definitely report any kind of performance > changes once this change goes into effect.My GCC installation here appears to inline g in the following example: inline int g(int x) { return x; } int main() { return g(3); } with just "-O1", but it doesn't do so when I drop the "inline" keyword. $ g++ --version g++43 (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. FWIW, Daveed
On Aug 26, 2009, at 7:02 PM, David Vandevoorde wrote:>> It's actually the other way around. llvm has always ignored the >> "inline" keyword and now we are finding out we are missing some >> important cases. > > Okay. It's the "other way around" in terms of history, but it looks > like the conclusion might be the same: Purely heuristics-based > inlining hasn't been proven entirely competitive yet (for C++)?That is what is unclear. We have no empirical evidence that listening to inline will improve the situation more than just increasing the inlining threshold across the board. Even if we did, I would still be uncomfortable with this: "hasn't been proven entirely competitive yet" implies that we've pursued the current inliner and tried hard to make it better without listening to inline. In fact, the current inliner is almost completely untuned and has many known problems. I am concerned that "listening to inline" will paper over other things that could be solved in much better ways. If the inlining heuristics were already considered to be well tuned and a study showed that 'listening to inline' was better than increasing the threshold, then I'd be a believer. I am also much more pessimistic about the world's C++ code than some. It turns out that not all c++ programmers are totally awesome :)> My GCC installation here appears to inline g in the following example: > > inline int g(int x) { return x; } > > int main() { > return g(3); > } > > with just "-O1", but it doesn't do so when I drop the "inline" > keyword.LLVM already does that at -O1 without listening to inline because the code is obviously smaller with the inline. -Chris