[cfe-dev] always_inline and noinline attributes

[Devang Patel]

On Jul 22, 2008, at 12:08 AM, Matthijs Kooijman wrote:

>> I'd strongly prefer to do this in the LLVM IR level instead of on  
>> clang
>> ASTs.
> That was the plan, AFAIU. Yet it would make sense to have clang do  
> it at the
> end of its compilation (by running an inliner over the generated IR).
>
>> 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.

Chris, that's why I used the word "hope" :).  I think, in real world,  
if a function is mark as always_inline in one translation unit, then  
it is always (:)) marked as always_inline in all translation unit.

However, If  the semantics requires always_inline to not cross  
translation unit limit during LTO then the optimizer needs a notion of  
inlining scope or something like that.

>> Woah, you're saying to only do inlining withing a translation unit?  
>> Does this
> mean that inlining does not happen at all in LTO?

Matthijs,  This means, always_inline is not enforced while doing  
inlining at LTO. In other words, inlining still happens but  
always_inline  does not override normal inline heuristics used by the  
inliner.

> I would say that inlining is
> one of the more obvious uses for LTO and IMHO it would be a waste  
> not to do it
> because it would change broken programs. Could you perhaps give an  
> example of
> a use that would be semantically changed by inlining?
>
> At the very least, I would make it an option whether to strip the
> always_inline info after compiling a single translation unit, so  
> people can
> explicitely choose to still do (forced) inlining at link time.

This may not be possible in all cases.
-
Devang