Long Fei
2005-Jul-07 20:52 UTC
[LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
I am investigating some inlining issue, so I did llvm-gcc aaa.c bbb.c ... nnn.c -o output opt -inline -inline-threshold=xxx < output.bc | llc -march=c > output_inline.c 1) I noticed that even if I set xxx to 0 or even a very small negative number, many functions are eliminated. I am wondering if these functions are inlined by the frontend, or identified as deadcode. For instance, SPEC2k bzip2 has 79 functions, after these two steps, only 61 functions are left. no other optimizations are used. 2) I noticed that the inlining condition (in Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not during the opt phase ? Can anybody explain what happens during llvm-gcc and opt respectively ? thanks, --Long
John Criswell
2005-Jul-07 21:09 UTC
[LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
Long Fei wrote:> > I am investigating some inlining issue, so I did > > llvm-gcc aaa.c bbb.c ... nnn.c -o output > opt -inline -inline-threshold=xxx < output.bc | llc -march=c > > output_inline.cI am unsure of whether the LLVM GCC frontend does any inlining. However, I do know that your methods above run the LLVM inlining pass, albeit indirectly. If you use llvm-gcc to generate and link LLVM bytecode files (as you do in the example above), llvm-gcc runs gccas and gccld (the optimizing assembler and optimizing linker, respectively). Both gccas and gccld run various LLVM optimizations, including inlining. This allows llvm-gcc to automatically perform interprocedural optimizations. To get a completely unoptimized bytecode file, do the following: llvm-gcc aaa.c bbb.c ... nnn.c -Wa,-disable-opt -Wl,-disable-opt -o output That should disable all LLVM optimizations. -- John T.> > 1) > I noticed that even if I set xxx to 0 or even a very small negative > number, many functions are eliminated. I am wondering if these functions > are inlined by the frontend, or identified as deadcode. > > For instance, SPEC2k bzip2 has 79 functions, after these two steps, only > 61 functions are left. no other optimizations are used. > > 2) > I noticed that the inlining condition (in > Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not > during the opt phase ? Can anybody explain what happens during llvm-gcc > and opt respectively ? > > > thanks, > --Long > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.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.
Misha Brukman
2005-Jul-07 22:15 UTC
[LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
On Thu, Jul 07, 2005 at 03:52:42PM -0500, Long Fei wrote:> I noticed that the inlining condition (in > Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not > during the opt phase ? Can anybody explain what happens during > llvm-gcc and opt respectively ?John answered the llvm-gcc part, so let me address the opt part. `opt' is a modular optimizer, but it will do exactly what you tell it to do, and nothing more, so if you say "opt -inline < input.bc > output.bc" it will only inline. Note that if you say "opt < old.bc > new.bc" opt will do nothing. This differs from gccas and gccld which have a built-in list of optimizations that they run, which you can get a list of if you follow the directions here: http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html#gccas http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html#gccld or just read their source code. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
Long Fei
2005-Jul-11 16:03 UTC
[LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
This didn't work as I tried with 197.parser. it works without "-Wl,-disable-opt" switch though. [197.parser]$ llvm-gcc analyze-linkage.c and.c build-disjuncts.c extract-links.c fast-match.c idiom.c main.c massage.c parse.c post-process.c print.c prune.c read-dict.c utilities.c xalloc.c word-file.c strncasecmp.c -Wa,-disable-opt -Wl,-disable-opt -lm -o llvm_parser [197.parser]$ opt -inline -inline-threshold=200 < llvm_parser.bc | llc -march=c > parser_inline.c llc: bytecode didn't read correctly. Does opt call Transform/IPO/InlineSimple to do inlining ? as I added instrumentation into it, I found: 1) getInlineCost() is called when doing llvm-gcc (without the -disable* flags) 2) getInlineCost() is not called when doing opt does the .bc code emitted by llvm-gcc carry inlining cost info ? otherwise, how does opt do inlining without the cost info ? thanks, --Long Misha Brukman wrote: On Thu, Jul 07, 2005 at 03:52:42PM -0500, Long Fei wrote:>I noticed that the inlining condition (in >Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not >during the opt phase ? Can anybody explain what happens during >llvm-gcc and opt respectively ? > >John answered the llvm-gcc part, so let me address the opt part. `opt' is a modular optimizer, but it will do exactly what you tell it to do, and nothing more, so if you say "opt -inline < input.bc > output.bc" it will only inline. Note that if you say "opt < old.bc > new.bc" opt will do nothing. This differs from gccas and gccld which have a built-in list of optimizations that they run, which you can get a list of if you follow the directions here: http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html#gccas http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html#gccld or just read their source code. John Criswell wrote:> Long Fei wrote: > >> >> I am investigating some inlining issue, so I did >> >> llvm-gcc aaa.c bbb.c ... nnn.c -o output >> opt -inline -inline-threshold=xxx < output.bc | llc -march=c > >> output_inline.c > > > I am unsure of whether the LLVM GCC frontend does any inlining. > However, I do know that your methods above run the LLVM inlining pass, > albeit indirectly. > > If you use llvm-gcc to generate and link LLVM bytecode files (as you > do in the example above), llvm-gcc runs gccas and gccld (the > optimizing assembler and optimizing linker, respectively). Both gccas > and gccld run various LLVM optimizations, including inlining. This > allows llvm-gcc to automatically perform interprocedural optimizations. > > To get a completely unoptimized bytecode file, do the following: > > llvm-gcc aaa.c bbb.c ... nnn.c -Wa,-disable-opt -Wl,-disable-opt -o > output > > That should disable all LLVM optimizations. > > -- John T. > >> >> 1) >> I noticed that even if I set xxx to 0 or even a very small negative >> number, many functions are eliminated. I am wondering if these >> functions are inlined by the frontend, or identified as deadcode. >> >> For instance, SPEC2k bzip2 has 79 functions, after these two steps, >> only 61 functions are left. no other optimizations are used. >> >> 2) >> I noticed that the inlining condition (in >> Transforms/IPO/InlineSimple.cpp) is tested during llvm-gcc but not >> during the opt phase ? Can anybody explain what happens during >> llvm-gcc and opt respectively ? >> >> >> thanks, >> --Long >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > >
Maybe Matching Threads
- [LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
- [LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
- [LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?
- [LLVMdev] function inlining threshold ?
- [LLVMdev] Removing inlining of library functions