Dale Johannesen <[EMAIL PROTECTED]> writes:

>>> 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.

Oh!  Sorry, I should have read your example more carefully.  I thought
we weren't running the inliner at all at -O0 still.

This is an intrinsic flaw in function-at-a-time mode.  I think at this
point it would be reasonable to make unit-at-a-time mode the default
at -O0, while preserving -fno-unit-at-a-time for things like crtstuff
(we eventually want to make that mode go away entirely, but we can't yet).

Then, for the sake of people who try to use both always_inline and
-fno-unit-at-a-time, we could improve the diagnostic -

  sorry, not implemented: inlining failed in call to 'a': function body
                          not yet seen
  note: this restriction does not apply in -funit-at-a-time mode

or something like that.

>> 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?

I don't know a pointer, but it's easy enough to summarize ...
Unit-at-a-time mode does not preserve the relative ordering of
functions and top-level asm() statements.  crtstuff.c uses top-level
asm() statements (and asm() statements within functions) to change
sections behind the compiler's back.  It therefore breaks when
compiled in unit-at-a-time mode.

Long term I'd like to see most of the code moved from crtstuff.c to
libgcc and the remainder written in assembly for each target, but
other projects have done similar tricks (e.g. glibc's crt[in].o are
generated similarly) and I don't think we want to unilaterally break
them.

zw

Reply via email to