[LLVMdev] Does the gcc frontend do inlining or deadcode elimination ?

[Long Fei]

Chris,

I tried what you said in last email. It didn't work as expected.

[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 -lm -W[al],-disable-inlining -o llvm_parser
[hash inlined] [table_pointer inlined] ...

[197.parser]$ opt -inline -inline-threshold=200 < llvm_parser.bc | llc 
-march=c > parser_inline.c
<no message here>

The "[xxx inlined]" message is generated from instrumentation in 
getInlineCost() (I changed it a little bit so it returns 0 if the callee 
is in a list of must-inline functions, it spits out this message in this 
case). It seems that getInlineCost() is evaluated only in llvm-gcc (even 
when -disable-inlining flag is set) but not in opt -inline. [If you 
disable inlining by returning a very large cost, it might explain.]

I will send another email with the .bc file directly to your email 
address (in order to get around the mailing-list manager).

thanks,
--Long


Chris Lattner wrote:

> On Mon, 11 Jul 2005, Long Fei wrote:
>
>>
>> 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
>
>
> Note that this will do NO optimization at all, giving you a very very 
> ugly .bc file.  You might try just -W[al],-disable-inlining instead of 
> disabling all optimization.
>
>> [197.parser]$ opt -inline -inline-threshold=200 < llvm_parser.bc | 
>> llc -march=c > parser_inline.c                       llc: bytecode 
>> didn't read correctly.
>
>
> This should work, what does opt print?  Can you send me [off list] the 
> llvm_parser.bc file?
>
>> Does opt call Transform/IPO/InlineSimple to do inlining?
>
>
> Yes.
>
>> as I added instrumentation into it, I found:
>> 1) getInlineCost() is called when doing llvm-gcc (without the 
>> -disable* flags)
>
>
> Yes, by default llvm-gcc does optimization, including inlining.
>
>> 2) getInlineCost() is not called when doing opt
>
>
> I assume that this is because opt is crashing or something (which is 
> why LLC complains).  Please send me the .bc file and I'll try to 
> figure out what is going on.
>
>> does the .bc code emitted by llvm-gcc carry inlining cost info ? 
>> otherwise, how does opt do inlining without the cost info ?
>
>
> No, the bc file contains no inlining information.  The inlining pass 
> looks at the IR for the callee and caller and uses heuristics to 
> decide the cost of inlining at each call site.  The code for this 
> lives in lib/Transforms/IPO as misha pointed out before.
>
> -Chris
>
>> 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
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> -Chris
>