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

[Dale Johannesen]

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?