[cfe-dev] always_inline and noinline attributes

[Matthijs Kooijman]

Hi all,

I think that a lot of confusion arises from unclarity about what always_inline
actually means.

The gcc docs [1] say:
	Generally, functions are not inlined unless optimization is specified. For
	functions declared inline, this attribute inlines the function even if no
	optimization level was specified.

This is not very specific on topics on taking function pointers and different
translation units, though. I see roughtly two options:

1) A function marked always_inline must always be inlined. This means it
cannot be used in other way, so taking the address of an always_inline
function is an error.

2) A function marked always_inline must be inlined whenever possible. This
means that any other uses simply won't get inlined, but are allowed.

Neither of these options would actually limit the visibility of thefunction,
as far as I can see. When the function is static, the function can normally be
DCE'd after inlining (which will always happen for 1), but might not happen
for 2)).

We could make always_inline work only with static functions, but I can't
really see why that would be necessary. IMHO, it would even greatly reduce the
usefulness of always_inline.

When the function is not static, it will still be inlined at all the callsites
within the same translation unit. We then have again two interpretations:

a) An always_inline attribute only works within the same translation unit.
Functions that are visible outside of the unit, are treated just as any other
function at link time, as if the always_inline attribute was not specified.

b) An always_inline attribute stays with a function, regardless of its
visibility. Any call site of the function, regardless of the translation unit
in which it lives, is inlined.

Option a) would be easiest to implement, but again lose a lost of usefulness
compared to option b). Option b) does require that inlining happens again at
link time, so any call sites in other translation units are inlined as well.

Also, option b) would be slightly tricky to combine with option 1), unless the
always_inline attribute is (can be) present on the definition as well as the
declaration of the function. Option b) combined with option 2) shouldn't have
this problem.

I think that Chris is really in favour of option b) here, because "inlining
can sometimes change semantics". However, I still don't really understand what
kind of cases we are talking about. Chris, could you give an example? Also, is
this changing of semantics specific to always_inline? From what you wrote, I
would assume that this changing of semantics can happen with any inline, so
you shouldn't be doing any inlining at all at link time. Nor at optimization
time, for that matter, so I'm probably missing an essential point here :-)

Also, Devang pointed out that inlining at link time might not be possible in
all cases. Again, the only case I can think of is taking the address of a
function, but this could easily be solved by using option 2), ie inline
whenever possible and leave the original function otherwise.

Furthermore, for our project we do actually need to have option b). AFAICS
option b) is fine as the default, but apparently I'm missing something there.
In any case, it would be very convenient to at least support option b), even
when it is not the default. This could perhaps be done through commandline
options to clang and/or the linker, or at the very least through options that
we can set in our own compiler driver (which links against clang,
transformation passes and the linker libraries).

So, which are the semantics that always_inline imply? What does gcc do?

Gr.

Matthijs

[1]: http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Function-Attributes.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080723/3f7a1884/attachment.sig>