[LLVMdev] Inline hints for *compiler clients*

[Vikram S. Adve]

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