Duncan:
I am only superficially familiar with LLVM structure.
What I am trying to find out is if functions that have a single invocation
are still found in the code during the compilation.
In Open64 and other compilers, there is an early inlining pass that inlines
all procedures that have a single invocation site. The reasoning is that if
there is a single call to a procedure, then there is not downside to
inlining it.
Does LLVM usually does that? Or would that be left to whatever front-end is
being used?
--
Cheers,
Nelson
/
\ / / Jose Nelson Amaral - amaral at cs.ualberta.ca
) / ( Professor
/ / \ Dept. of Computing Science - University of Alberta
( / ) Edmonton, Alberta, Canada, T6G 2E8
\ O / Phone: (780)492-5411 Fax: (780)492-1071
\ / http://www.cs.ualberta.ca/~amaral
`----'
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101024/88258fca/attachment.html>
Hi Nelson,> What I am trying to find out is if functions that have a single invocation are > still found in the code during the compilation.I'm pretty sure that static functions with a single invocation are always inlined. If doing link-time optimization, then pretty much any function with a single invocation will be inlined. I'm not sure what this has to do with "early inlining". Ciao, Duncan.
Nelson, As far as I know, there are only 2 inliners available in LLVM (2.7 and 2.8 releases): InlineSimple: inline callsites according to simple analysis heuristics InlneAlways: inline callsites whose callee definitions have the __attribute__((alwayeinline)) attribute on. For an early inliner, if doesn't exist, it should be relatively straight forward to write one. Chuck On 10/24/2010 1:23 PM, J Nelson Amaral wrote:> Duncan: > > I am only superficially familiar with LLVM structure. > > What I am trying to find out is if functions that have a single > invocation are still found in the code during the compilation. > > In Open64 and other compilers, there is an early inlining pass that > inlines all procedures that have a single invocation site. The > reasoning is that if there is a single call to a procedure, then there > is not downside to inlining it. > > Does LLVM usually does that? Or would that be left to whatever > front-end is being used? > > -- > Cheers, > > Nelson > > / > \ / / Jose Nelson Amaral - amaral at cs.ualberta.ca > <mailto:amaral at cs.ualberta.ca> > ) / ( Professor > / / \ Dept. of Computing Science - University of Alberta > ( / ) Edmonton, Alberta, Canada, T6G 2E8 > \ O / Phone: (780)492-5411 Fax: (780)492-1071 > \ / http://www.cs.ualberta.ca/~amaral > <http://www.cs.ualberta.ca/%7Eamaral> > `----' > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101024/5bdf9b26/attachment.html>
A static function with a single invocation gets a very high weight in
the inlining heuristics. But a sufficiently large function still
won't get inlined (not sure I've ever seen this in practice), and we
don't know how to inline some functions, such as those that use
varargs. There are also more complicated cases (I'm not sure we check
for this one; it's come up at least twice in practice, but that was
before llvm came along, and I think the source was hacked to work
around the problem in both cases):
a() { char x[10000000]; ....}
b() { a(); .... b(); .... }
It's probably a bad idea to inline a() even if the call shown is the
only one; it won't take many recursive calls to b() to blow the stack.
On Oct 24, 2010, at 10:44 AM, Duncan Sands wrote:
> Hi Nelson,
>
>> What I am trying to find out is if functions that have a single
>> invocation are
>> still found in the code during the compilation.
>
> I'm pretty sure that static functions with a single invocation are
> always
> inlined. If doing link-time optimization, then pretty much any
> function
> with a single invocation will be inlined.
>
> I'm not sure what this has to do with "early inlining".
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Oct 24, 2010, at 10:23 AM, J Nelson Amaral wrote:> Duncan: > > I am only superficially familiar with LLVM structure. > > What I am trying to find out is if functions that have a single invocation are still found in the code during the compilation. > > In Open64 and other compilers, there is an early inlining pass that inlines all procedures that have a single invocation site. The reasoning is that if there is a single call to a procedure, then there is not downside to inlining it.There is not one but it is easy to write. LLVM inliner implementation is modular. It is easy to add new inliner based on your home grown heuristics. InlineSimple is standard inliner tuned for the needs of general purpose optimizations. It can be run multiple times. InlineAlways is a very simple instance of special inliner where it only inlines functions that are marked as "always_inline". It would be very simple to write another special inliner for you needs. All you need to do is identify functions that have single call site. See InlineAlways.cpp for an example of a special inliner. - Devang> > Does LLVM usually does that? Or would that be left to whatever front-end is being used?-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101025/980b4fa1/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Reviewer for our Path Profiling Implementation
- [LLVMdev] How can we recruit a reviewer for our path-profiling implementation?
- [LLVMdev] Reviewer for our Path Profiling Implementation
- [LLVMdev] inline callsites whose function definitions are in different file?
- [LLVMdev] inline callsites whose function definitions are in different file?