Re: RFC: always-inline vs unit-at-a-time

[Dale Johannesen <dalej at apple dot com>]

On Mar 15, 2005, at 10:32 AM, Zack Weinberg wrote:

> Dale Johannesen <dalej@apple.com> writes:
>
> > Consider the following:
> >
> > static inline int a() __attribute((always_inline));
> > static inline int b() __attribute((always_inline));
> >
> > static inline int b() { a(); }
> > static inline int a() { }
> > int c() { b(); }
> >
> > This compiles fine at -O2.  At -O0 we get the baffling error
> >    sorry, unimplemented: inlining failed in call to 'a': function not
> >    considered for inlining
> >
> > It seems undesirable for -O options to affect which programs will
> > compile.
>
> Agreed.  Perhaps we should run the inliner at -O0 if we see
> always_inline attributes, just for those functions?

We do; the problem is that it makes only 1 pass, so tries to inline
"a" before it has seen the body of "a".  If you interchange the 
definitions
of "a" and "b" the inlining is done at all optimization levels.

> I think this
> could be done without turning on -funit-at-a-time, even (the inliner
> does work in -O2 -fno-unit-at-a-time mode, after all).

That gets the same failure on this example.

> The problem is not the effect on compile speed (IIRC Honza had it down
> to negligible) but the way it breaks assembly hacks such as crtstuff.c.
> (I would love to see a solution to that.)

I wasn't aware of this problem, can you give me a pointer?