llvm dev - Jul 2005 - [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
>
>
>

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

-- 
http://nondot.org/sabre/
http://llvm.org/

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
>