[LLVMdev] Inline hints for *compiler clients*

[Chris Lattner]

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/