[cfe-dev] always_inline and noinline attributes

Chris Lattner clattner at apple.com
Mon Jul 21 16:07:40 PDT 2008

On Jul 18, 2008, at 2:09 PM, Matthijs Kooijman wrote:
>> Once the information is encoded in the IR, the remaining issue is  
>> how to
>> invoke the LLVM inlining pass when at least one function is marked as
>> always_inline. There are two possible approaches:
>> 1) Teach FE tools (e.g. clang, llvm-gcc) to insert inlining pass in  
>> the
>> PassManager while requesting (opt + code generation) when it least  
>> one
>> function with attribute always_inline is seen.
> Perhaps there could be a specific inliner that does only this? This  
> prevents
> surprises when people didn't expect inlining?

I'd strongly prefer to do this in the LLVM IR level instead of on  
clang ASTs.

>> 2) Teach the LLVM PassManager to sniff always_inline property  
>> encoded in
>> the LLVM IR and do the right thing.
> This sounds like it might also surprise people, if they only add a  
> single pass
> and still things are inlined. Might not be a big problem, though.

GCC runs its inliner, even at -O0.  I agree it is ugly, but seems  

> Another reason why I think encoding in the IR is necessary: If I  
> have an
> always inline function defined in one module and referenced in  
> another, I
> think it should still be inlined after I link the two modules  
> together, right?

No, it should only happen within a translation unit.  The semantics of  
the program should not change based on whether you're using LTO or  
not, and inlining can sometimes change semantics for (arguably very  
broken) uses.


More information about the cfe-dev mailing list