[LLVMdev] Inline hints for *compiler clients*

[John Criswell]

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.