[llvm-dev] Understanding LLVM Optimization (Rpass=inline)

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 4 10:32:59 PDT 2018


On 9/3/2018 11:20 AM, praveen via llvm-dev wrote:
>
> Dear LLVM community :-)
>
> I'm a novice in compiler principles and optimization, I'm currently 
> working with some example code to see what && how LLVM optimization is 
> doing to generate good machine code. While working  I find some 
> functions are being inlined by llvm and some are not, but I don't know 
> the internals of optimization so I can't able to figure  the reasons 
> and rationale behind them.
>
> For example:
>
> struct value{
>
> int set(){} // Function does nothing!
>

Pay attention to the compiler warnings... in particular, this triggers 
"warning: control reaches end of non-void function", which substantially 
changes the generated code.

Sometimes the compiler can eliminate a call to a function without 
actually "inlining" it; if a call has no side effects, and the result is 
unused, it will be erased because it's dead.  LLVM currently doesn't 
emit a remark when this happens.

> Could you please share some pointers (videos or blogs) which explains 
> the design of llvm optimizations :-). And also what is mean by _/cost 
> and threshold in inlining functions?/_/like (cost=always and 
> cost=never). /_/
> /_
>

The "cost" is roughly how expensive it would be to inline the function 
in question, in terms of codesize.  The units don't really mean anything 
in particular, but a simple instruction is roughly 5 units.  
Always/never are overrides to say the function in question should 
always/never be inlined; for example, if a function is marked with 
__attribute__((always_inline)) or __attribute((noinline)).

> _//_
>
> Next,
>
> Clang documentation (here 
> <https://clang.llvm.org/docs/UsersManual.html#cmdoption-wambiguous-member-template>) 
> mentions that -_/Wambiguous-member-template/_ warning _is defaulted to 
> on_. But when I actually compile the same code as in documentation it 
> doesn't throw up any warnings. Is the documentation is out-dated for 
> clang 8.0.0 ?
>

I think the warning only triggers with -std=c++03, because the rules 
changed in C++11.  Maybe the documentation should be clarified.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180904/8baced5a/attachment.html>


More information about the llvm-dev mailing list