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/
On Wed, 15 Mar 2006, Vikram S. Adve wrote:>> 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.I'm not following. Why do you want to uninline stuff? If we had a 'never inline these functions' list, a transformation could add any function it wants to this list to prevent the inliner from inlining it in the future. Aside from that, I don't see what uninlining has to do with inlining heuristics, can you explain a bit more?> (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.You're talking about something like 5 lines of code, plus the predicate deciding whether to inline it or not (which you'd need anyway).> (3) If multiple passes want such control, this would end up duplicating the > driver code.Again, this is a trivial amount of code. Giving passes the ability to modify the heuristics used by the inliner would significantly dwarf this in both amount of code and complexity. What are you really trying to do here? Can you provide an example? -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Mar 15, 2006, at 11:15 AM, Chris Lattner wrote:> On Wed, 15 Mar 2006, Vikram S. Adve wrote: >>> 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. > > I'm not following. Why do you want to uninline stuff? If we had a > 'never inline these functions' list,We don't have such a list, at least not so far. We do have a "used" list but that's presumably used for other things.> a transformation could add any function it wants to this list to > prevent the inliner from inlining it in the future. > > Aside from that, I don't see what uninlining has to do with > inlining heuristics, can you explain a bit more?I'm not sure what there is to explain. Inlining heuristics control what to inline. If you're writing a tool, you'd want to run the inliner while influencing what it chooses to inline.>> (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. > > You're talking about something like 5 lines of code, plus the > predicate deciding whether to inline it or not (which you'd need > anyway).That's 5 more lines than if you simply wanted to influence the inlining heuristics.> >> (3) If multiple passes want such control, this would end up >> duplicating the driver code. > > Again, this is a trivial amount of code.I don't agree.> Giving passes the ability to modify the heuristics used by the > inliner would significantly dwarf this in both amount of code and > complexity.Again, I don't agree. I looked at the getInlineCost(const CallSite& CS) function. It has a dozen or more embedded constants in it. If those used symbolic constant indexes into a cost table, any tool could influence the heuristics simply by changing the values in the table, which (it seems to me) would be simple and intuitive.> > What are you really trying to do here? Can you provide an example?I was just trying to help John by following up on his issue. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/