[LLVMdev] Inline hints for *compiler clients*
Vikram S. Adve
vadve at cs.uiuc.edu
Wed Mar 15 14:02:18 PST 2006
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
> 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.
>> 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
>> 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.
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> 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
More information about the llvm-dev