[cfe-dev] always_inline and noinline attributes
dpatel at apple.com
Tue Jul 22 10:26:07 PDT 2008
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
> 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,
>> inlining can sometimes change semantics for (arguably very broken)
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
> 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.
More information about the cfe-dev