Re: -fobey-inline (was Re: gcc and inlining)

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Op ma 17-03-2003, om 00:30 schreef Richard Almquist:
> In the future, I think that the compiler should have a better idea about 
> what should be inlined than the programmer.  Therefore, in the long run 
> GCC should ignore the inline keyword.

Bah, how can anybody make such a claim?  "The compiler should ignore the
user input because it is smarter than the user".  Well, I'm pretty sure
none of us will be around to see that happen, if it's possible at all
without unreasonable costs.

Why? Because compilers will always be dumb piece of software, tuned by
humans to work well for most code.

Yes, a really good compiler can make the right decisions most of the
time.  But not *all* of the time!

Look again at kernel programming, or even better, at Alexandre's example
of a dynamic loader.  And those are just the very extreme examples, but
for some user code it might well be that the user sometimes has very
very good reasons to inline something when the compiler would not
normally consider that function for inlining.

Lets look at what information a compiler could use to make inline
decisions, ignoring recursive functions, functions that call alloca,
etc.:

(Correct me if I'm wrong, and I probably am ;-)
1) Size of a function (the number of instructions).  With tree
   inlining in GCC this is not a very good measure, because:
     a) It's impossible to tell how many insn per tree you,
        have, the best you can do is guestimate, and
     b) it's impossible to tell how much of the function can
        be optimized away.
   (a) may not be so bad for the old RTL inliner, but that one
   of course had its own drawbacks, and (b) still stands...

2) Effects on register pressure.  Again, hard to tell, just
   guessing is the best one can do.  GCC doesn't take this
   into account at all, it can't tell from trees obviously.

3) (can't think of other really important ones, though I guess
    there are...) 

All of these are probably true for any compiler.

Bottom line: It's just guess work, with some numbers and buttons to tune
it to work right on whatever test cases you have available.  There is
just no easy way to tell what's best for any given function.  All you
can do is find heuristics that work best for most cases.

Now back to the original statement: "The compiler will be able to ignore
the "inline" keyword."  Sorry, not true in all cases IMHO.

And *that* is why I would like to see that the final choice can be left
to the user, with -fobey-inline, or -finline-limit=kazillion or whatever
other flag/attribute/gizmo.

Greetz
Steven