[I've changed the subject to make this a new thread.] While all of this makes sense to me, note that Markus and John were asking about different situations. Markus was asking about user- written source code. John was asking about a compiler pass or tool written by a compiler developer, not a user. These arguments apply to users but not compiler developers. What do you think about the latter? --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Mar 7, 2006, at 12:35 PM, Chris Lattner wrote:> On Tue, 7 Mar 2006, Vikram S. Adve wrote: >> Changing the heuristics directly would have to be a custom change >> (i.e., couldn't be checked in). Is there a way for a client pass >> or tool to influence the heuristics? If not, does it make sense >> to add such a mechanism? > > To be clear, I'll restate my position here, then follow up with > more specifics of such a mechanism to Markus' email. > > My basic position is that I think it's a bad thing to let the user > have fine grained control over optimizations at the source level. > Being able to say "always force this to be inlined" will make less > or more sense as the compiler evolves. In particular, as the > compiler gets better at improving code, the decision about what to > inline will change, and code that uses thes attributes won't (the > authors of the code are unlikely to revisit the attributes after > they are written). > > As one particularly pointed example, the code that uses attributes > like 'always inline' are typically written and tuned for GCC, often > for old versions of it. GCC and LLVM (obviously) have very very > very different optimization capabilities (e.g. LLVM can do > interprocedural inlining, dead argument elimination, > interprocedural constant prop, etc), and forcing something to be > inlined for GCC has a very different impact than does forcing LLVM > to inline it. > > The meta problem with this is that the code will still *work*, it > will just perform more poorly than it should. As such, people are > very unlikely to revisit these attributes after they are initially > written. > > The above is a description of why I think that "always inline" is a > bad idea to support. However, I *do* [now] support the notion of > "never inline". In contrast with "always inline", never inline > sometimes isn't a performance hint: it can be a correctness hint > and is far more invariant across compiler versions than always > inline is. While it can obviously be abused, I think the chances > for its abuse are reduced. > > I will respond to Markus' mail with a concrete proposal for how > this could be implemented. > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Wed, 15 Mar 2006, Vikram S. Adve wrote:> [I've changed the subject to make this a new thread.] > > While all of this makes sense to me, note that Markus and John were asking > about different situations. Markus was asking about user-written source > code. John was asking about a compiler pass or tool written by a compiler > developer, not a user. > > These arguments apply to users but not compiler developers. What do you > think about the latter?Why can't the compiler pass just call InlineFunction(CallSite) on the callsite it wants inlined? The only way that can fail is if LLVM cannot ever inline the call (e.g. it uses varargs). -Chris> On Mar 7, 2006, at 12:35 PM, Chris Lattner wrote: >> On Tue, 7 Mar 2006, Vikram S. Adve wrote: >>> Changing the heuristics directly would have to be a custom change (i.e., >>> couldn't be checked in). Is there a way for a client pass or tool to >>> influence the heuristics? If not, does it make sense to add such a >>> mechanism? >> >> To be clear, I'll restate my position here, then follow up with more >> specifics of such a mechanism to Markus' email. >> >> My basic position is that I think it's a bad thing to let the user have >> fine grained control over optimizations at the source level. Being able to >> say "always force this to be inlined" will make less or more sense as the >> compiler evolves. In particular, as the compiler gets better at improving >> code, the decision about what to inline will change, and code that uses >> thes attributes won't (the authors of the code are unlikely to revisit the >> attributes after they are written). >> >> As one particularly pointed example, the code that uses attributes like >> 'always inline' are typically written and tuned for GCC, often for old >> versions of it. GCC and LLVM (obviously) have very very very different >> optimization capabilities (e.g. LLVM can do interprocedural inlining, dead >> argument elimination, interprocedural constant prop, etc), and forcing >> something to be inlined for GCC has a very different impact than does >> forcing LLVM to inline it. >> >> The meta problem with this is that the code will still *work*, it will just >> perform more poorly than it should. As such, people are very unlikely to >> revisit these attributes after they are initially written. >> >> The above is a description of why I think that "always inline" is a bad >> idea to support. However, I *do* [now] support the notion of "never >> inline". In contrast with "always inline", never inline sometimes isn't a >> performance hint: it can be a correctness hint and is far more invariant >> across compiler versions than always inline is. While it can obviously be >> abused, I think the chances for its abuse are reduced. >> >> I will respond to Markus' mail with a concrete proposal for how this could >> be implemented. >> >> -Chris >> >> -- >> http://nondot.org/sabre/ >> http://llvm.org/ >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
On Mar 15, 2006, at 10:04 AM, Chris Lattner wrote:> On Wed, 15 Mar 2006, Vikram S. Adve wrote: >> [I've changed the subject to make this a new thread.] >> >> While all of this makes sense to me, note that Markus and John >> were asking about different situations. Markus was asking about >> user-written source code. John was asking about a compiler pass >> or tool written by a compiler developer, not a user. >> >> These arguments apply to users but not compiler developers. What >> do you think about the latter? > > Why can't the compiler pass just call InlineFunction(CallSite) on > the callsite it wants inlined? The only way that can fail is if > LLVM cannot ever inline the call (e.g. it uses varargs).In some cases, that would be fine. But in other cases: (1) It cannot "un-inline" any function that was previously inlined. (2) It requires writing a driver loop nest to go over all call sites and decide what to do. If all you want is to influence the existing heuristics, that seems like too much work. (3) If multiple passes want such control, this would end up duplicating the driver code. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/