C: inline without forcing?

Danielle Church dani.church@gmail.com
Wed Jun 2 16:22:58 GMT 2021

On Wed, Jun 2, 2021 at 11:54 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Wed, Jun 02, 2021 at 11:25:23AM -0400, Danielle Church via Gcc-help wrote:
> > In any case; does this mean that the only way to put a function
> > definition into a file without GCC emitting standalone code for it is
> > to use the C99 inline keyword, which alters the behavior of the
> > optimizer?
> Does it?  What makes you think it does?
> There are some differences to heuristics, but are you actually seeing
> any, or is this a hypothetical thing?

Well, first, I'm looking at the output of -fopt-info-inline-all from
the original version (in which the two files are merged into a single
TU), and I see that there are some marginal functions that are just a
little on the large side, and they only get inlined at some but not
all of the call sites. If I provide the definition of one of those
functions with the inline keyword during separate compilation, though,
it gets inlined every single time, leading to some massive function
growth. Second—and, presumably, related to loss of locality/cache
pressure—my benchmarks on the separate-compilation version, when I've
copied every relevant (according to -fopt-info-inline-all) function
definition into the calling file's TU using C99 inline semantics,
loses about 5~10% compared to the single-TU version.

> > Is there no way to get the code-emit behavior (inline the
> > function or emit a TU-external reference, don't emit standalone
> > definition) without the optimizer changes (more likely to inline the
> > function, even if it's a bad idea)?
> extern attribute((gnu_inline))

Does ``extern inline attribute((gnu_inline))'' behave appreciably
differently than C99's bare ``inline''? They seem to have the same
effect from the documentation, though with reversed semantics for the
presence vs absence of the extern keyword.


More information about the Gcc-help mailing list