[LLVMdev] What are the equivalents of gcc inline control options like max-inline-insns-single in clang?
Yuri
clang: warning: argument unused during compilation: '-finline-limit=50'
clang: warning: argument unused during compilation: '--param
max-inline-insns-single=50'
clang: warning: argument unused during compilation: '--param
max-inline-insns-auto=12'
clang: warning: argument unused during compilation: '--param
large-function-insns=300'
clang: warning: argument unused during compilation: '--param
large-function-growth=20'
clang: warning: argument unused during compilation: '--param
inline-unit-growth=100'
These options work with gcc and not with clang.
What are the clang equivalents?
Yuri
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Chris Lattner
On Feb 19, 2011, at 6:12 PM, Yuri wrote:
> I got these warnings:
> clang: warning: argument unused during compilation: '-finline-limit=50'
> clang: warning: argument unused during compilation: '--param
> max-inline-insns-single=50'
> clang: warning: argument unused during compilation: '--param
> max-inline-insns-auto=12'
> clang: warning: argument unused during compilation: '--param
> large-function-insns=300'
> clang: warning: argument unused during compilation: '--param
> large-function-growth=20'
> clang: warning: argument unused during compilation: '--param
> inline-unit-growth=100'
>
> These options work with gcc and not with clang.
> What are the clang equivalents?
Clang doesn't expose any equivalent.
-Chris
Yuri
> Clang doesn't expose any equivalent
Why not?
Such controls are useful to tune the level of optimization. For example
from my experience forcing more inlining causes code to grow due to
resulting duplication but often such code is also faster. Even though
cache mishits may cause it to slow down too eventually. Speed is vital
for software in many industries.
User should be able to force-flatten the module leaving only interface
functions. On the other hand user may want to lower the inlining level
to speed up compilation.
Yuri
Anton Korobeynikov
>> Clang doesn't expose any equivalent
>
> Why not?
Also, such options tend to have different semantics in different
versions of the compiler.
--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University
Chris Lattner
On Feb 19, 2011, at 6:40 PM, Yuri wrote:
> On 02/19/2011 18:29, Chris Lattner wrote:
>> Clang doesn't expose any equivalent
>
> Why not?
It's a policy decision. These flags are not stable but users feel compelled to use them and then stick them in their makefiles. We should aim to make the compiler "do the right thing" (e.g. with just -O2 and -O3) and make that be enough for people.
When people add flags like this to their makefiles, future changes in the compiler *pessimize* the code, because the old code tuned against a previous compiler is being built with *wrong* inline thresholds.
> Such controls are useful to tune the level of optimization. For example
> from my experience forcing more inlining causes code to grow due to
> resulting duplication but often such code is also faster. Even though
> cache mishits may cause it to slow down too eventually. Speed is vital
> for software in many industries.
I agree, we should just make the compiler faster without the flags.
> User should be able to force-flatten the module leaving only interface
> functions.
The GCC folks have an __attribute__((flatten)) or something like that, which provides that. This approach allows developers to express their goal, not a random number.
> On the other hand user may want to lower the inlining level
> to speed up compilation.
They can build at -O2.
For compiler hackers, the opt/llc command line flags are exposed from clang/llvm-gcc with the -mllvm option.
-Chris