llvm dev - Sep 2018 - Understanding LLVM Optimization (Rpass=inline)

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!

};

void foo () {} // Function does nothing!

void func( ) {

value obj;

obj.set();

foo();

}

Compiling with command  "clang++ -O2 -std=c++11 
-stdlib=libc++/__//_*-Rpass=inline*_/ name.cpp prints

only obj.set() was inlined but not foo(). I don't understand the 
rationale behind this (both are empty functions right ?). Why LLVM not 
inlining the function "foo" ?

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). /_/
/_

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 ?

Software details :

Clang 8.0.0 , Linux mint.

Hardware details:

X86-64 bit.

Could you please share your knowledge for the above questions ? it is a 
great help to me

Thank you very much for your time,

PreeJackie

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180903/1090e3c7/attachment.html>

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>