[llvm-commits] [llvm] r95466 - in /llvm/trunk: bindings/ocaml/llvm/llvm.ml bindings/ocaml/llvm/llvm.mli docs/LangRef.html include/llvm-c/Core.h include/llvm/Attributes.h include/llvm/Transforms/IPO/InlinerPass.h lib/AsmParser/LLLexer.cpp lib/AsmParser/LLParser.cpp lib/AsmParser/LLToken.h lib/Target/CppBackend/CPPBackend.cpp lib/Transforms/IPO/Inliner.cpp lib/VMCore/Attributes.cpp utils/llvm.grm utils/vim/llvm.vim

Dan Gohman gohman at apple.com
Mon Feb 8 11:43:34 PST 2010


On Feb 7, 2010, at 10:16 AM, Jakob Stoklund Olesen wrote:

> 
> On Feb 5, 2010, at 10:45 PM, Nick Lewycky wrote:
> 
>> Jakob, it sounds like this is actually experimental. Assuming you don't make any progress between now and the time the branch is created, should this patch be backed out of the 2.7 release? Realize that if we don't, we're stuck with a bit allocated to the InlineHint function attr in the bitcode until 3.x.
> 
> There are two separate issues here:
> 
> 1. Should the C99 and C++ inline keyword affect the optimizer?
> 2. If so, how?
> 
> The consensus is that the first answer is yes, the inline keyword should affect the optimizer. Without profiling data it is very difficult to make the right size/performance tradeoff, and the inline keyword can help.

The rest the story here is that GCC uses the inline keyword to adjust its
heuristics, and there are influential codebases which have come to expect
GCC's inlining heuristics. 

Dan





More information about the llvm-commits mailing list