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/
Vikram S. Adve wrote: Hmmm. It seems the discussion has grown a little bit larger than I had intended. :) Basically what I think would be useful is an option to the inliner that gives it a list of functions to skip when inlining. My argument for this is that we have several transformations now that search for calls to specific functions; if those functions are inlined, the transform pass can no longer find the calls. I would like the list of functions excluded from inlining to be specified on the command line (as I'm using the LLVM opt command); providing a constructor to the Inliner pass that takes a list of function names to exclude from inlining might also be handy to LLVM programmers but is beyond what I need at the moment. I think Chris indicated in an earlier email that such a command line option is now okay. Chris, please let me know if I understand that correctly. The ability to control inlining from the source code being compiled (i.e. GCC's noinline attribute), adjust the inlining heuristics programmatically from a custom built LLVM tool, etc, are beyond the scope of what I need. Hopefully that clears up what I was asking about. -- John T.> > 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/ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- John T. Criswell Research Programmer University of Illinois at Urbana-Champaign "It's today!" said Piglet. "My favorite day," said Pooh.
On Mar 15, 2006, at 3:27 PM, John Criswell wrote:> Vikram S. Adve wrote: > > Hmmm. It seems the discussion has grown a little bit larger than I > had intended. > :) > > Basically what I think would be useful is an option to the inliner > that gives it a list of functions to skip when inlining. My > argument for this is that we have several transformations now that > search for calls to specific functions; if those functions are > inlined, the transform pass can no longer find the calls. > > I would like the list of functions excluded from inlining to be > specified on the command line (as I'm using the LLVM opt command); > providing a constructor to the Inliner pass that takes a list of > function names to exclude from inlining might also be handy to LLVM > programmers but is beyond what I need at the moment.That seems fine. I just think a more general mechanism that does not have greater complexity is better than a narrower one. In this case, replacing the constants with a lookup table that can be modified by any tool seems like a simple and general way to implement your option, or the constructor for the Inliner pass, or more sophisticated tools.> I think Chris indicated in an earlier email that such a command > line option is now okay. Chris, please let me know if I understand > that correctly. > > The ability to control inlining from the source code being compiled > (i.e. GCC's noinline attribute), adjust the inlining heuristics > programmatically from a custom built LLVM tool, etc, are beyond the > scope of what I need.The former is certainly much more complicated. The latter (controlling heuristics from an LLVM tool) does not seem to be significantly more complicated.> > Hopefully that clears up what I was asking about. > > -- John T.Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/> >> 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/ >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > -- > John T. Criswell > Research Programmer > University of Illinois at Urbana-Champaign > "It's today!" said Piglet. "My favorite day," said Pooh. > > _______________________________________________ > 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:> 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.Yes, of course. However, as stated earlier in the thread, that is just because noone has done it yet. If you would like to implement it, go for it, I'd be happy to have it in LLVM.>> 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.Example please.>>> (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.And potentially hundreds of lines elsewhere, that are much more complex.>>> (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.5 lines isn't trivial?>> 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.where would this table live? Who would maintain it? When function are added and deleted from the program, who updates the table? Do you propose all of the optimizations (which touch functions) the linker, the assembler and disassembler, the .ll and .bc formats all be updated to support this table? Again, 5 lines of code is trivial compared to the alternative.>> 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.Without concrete details to discuss, you're just making hypothetical arguments. Please give me an example so I can understand the problem you are trying to solve. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On Wed, 15 Mar 2006, John Criswell wrote:> Vikram S. Adve wrote: > Basically what I think would be useful is an option to the inliner that gives > it a list of functions to skip when inlining. My argument for this is that > we have several transformations now that search for calls to specific > functions; if those functions are inlined, the transform pass can no longer > find the calls.Are these passes implemented in LLVM code? Is there any reason not the leave them as external function calls?> I would like the list of functions excluded from inlining to be specified on > the command line (as I'm using the LLVM opt command); providing a constructor > to the Inliner pass that takes a list of function names to exclude from > inlining might also be handy to LLVM programmers but is beyond what I need at > the moment.The easiest way to do this (if the "don't inline" list of functions was implemented) would be to have your pass (or write a new one) that adds these functions to the list of functions to not be inlined. If you want, you could write another pass to remove them when they are safe to inline.> I think Chris indicated in an earlier email that such a command line option > is now okay. Chris, please let me know if I understand that correctly.No, but if you want to implement the "never inline" list, that would be fine. I can discuss details again if you're interested.> The ability to control inlining from the source code being compiled (i.e. > GCC's noinline attribute), adjust the inlining heuristics programmatically > from a custom built LLVM tool, etc, are beyond the scope of what I need.Great to hear. -Chris>> 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/ >> >> >> _______________________________________________ >> 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/