[cfe-dev] always_inline and noinline attributes

[Eli Friedman]

On Fri, Jun 20, 2008 at 5:15 AM, Matthijs Kooijman <matthijs at stdin.nl> wrote:
> Gcc and llvm-gcc support the always_inline attribute for exactly this reason.
> Clang currently completely ignores this attribute. What would we the correct
> way of implementing this?

I think the right way would be to add a hook in
CodeGenModule::~CodeGenModule() that iterates over every always_inline
function, inlines them, then erases them.  This shouldn't be too hard
to implement; you can use the existing inlining code by including
llvm/Transforms/Utils/Cloning.h and adding libLLVMTransformUtils.a to
clang's link line.

> Currently, llvm-gcc supports always_inline by inlining those functions in the
> gcc part, even before the llvm inliner comes along to look at the program. We
> could take a similar approach in clang, though it seems like double work to
> me.
>
> Perhaps it would be better to take a route similar to what the noinline
> attribute does in llvm-gcc: Output a global variable in the llvm.metadata
> section with a list of all the force_inline functions. This ensures we can
> reuse the llvm inliner and could also be useful for other frontends. Any
> details I'm missing?

The issue is that always_inline means that inlining is a requirement,
not just a suggestion.  We have to make sure the functions are inlined
even if we don't run the inliner pass.  Any other way puts too much
burden on the users of emitted bitcode files.

> Furthermore, I was also looking at the "noinline" attribute (mainly as an
> example). It seems that llvm-gcc emits a llvm.noinline global variable
> containing references to functions with the noinline attribute. Clang however,
> parses the noinline keyword, but does not emit anything for it. Is this
> intentional, or did nobody get around to writing this yet?

AFAIK, nobody's written it yet.  Patches welcome.

-Eli