Such controls are useful to tune the level of optimization. For example 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.
Because clang's inlining / optimization stuff is different from gcc's ?
Also, such options tend to have different semantics in different
versions of the compiler.
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.