Re: A patch for linux 2.1.127

["Peter T. Breuer" <ptb at it dot uc3m dot es>]

"A month of sundays ago Linus Torvalds wrote:"
> How about something simple like:
> 
> 	if (SMALL_REGISTER_SET)
> 		never_inline_functions_unless_the_user_asked_for_it();
> 
> which means that even with -O6 you would not inline functions unless they
> were marked inline. 

Too much. I rely on gcc (and other compilers) inlining functions that are
only placeholders for other calls to optimize generated code.

I need functions inlined if they're dead-ends, or call other functions
and return the foreign result without further calculation.  I.e.  they
don't need to save and restore registers because they're not using any.
That's about a 3-4 times speedup win for me (my compiler-compilers ..).
I produce lots of short functions from expression analysis. "a+b+c"
might generate 6 functions, one for each subexpression and one for each
referent.

If gcc can't detect the (tail-recursion at worst) case its dataflow
analysis is fundamentally broken.  Given that it is broken, possibly
only for the assembler case (??  - isn't gcc using its
internal representation at this point?) it should at least be able to say
"i'm not sure" and fallback to saving/restoring registers.

> Note that this is not just a workaround for a bug. The fact is, that with

As phrased, it is! It looks more like one should just stop gcc being so
optimistic when it's data analysis doesn't warrant it.

> small-register-set, inlining functions is not likely to be all that big of
> a win (and is often a loss due to register allocation pressure) unless the
> function is _really_ small or for some special cases - and in both cases
> hopefully the function is marked inline already by the knowledgeable user.

The knowledgeable user relies on the knowledgable compiler here.  All
studies show that hand-optimizing code is a waste of effort 99.99% of
the time, not least because it's unmaintainable.  Experience says so
too.  I've regretted every "optimization" I've ever done.

Peter