[PATCH] misc size-shrinkage; merges

Rich Felker dalias at aerifal.cx
Wed Aug 30 17:37:56 UTC 2006


On Wed, Aug 30, 2006 at 12:31:51PM -0400, Rob Landley wrote:
> On Wednesday 30 August 2006 3:14 am, Bernhard Fischer wrote:
> > Still, IMO it's better to be sure that explicit inline's are handled
> > correctly (as in the setjmp cases) than to fail for some users in
> > possible obscure ways.
> 
> Did you miss -finline-limit-0 going in back around...  April, was it?
> 
> ATTRIBUTE_ALWAYS_INLINE should always inline.  The "inline" keyword should 
> never inline now, and all occurrences if it should either be converted to the 
> attribute or should be removed.  (And it was never more than a recommendation 
> anyway.  Like "register", it has little place with a modern compiler.)

I don't think it's quite the same as register. A reasonable user would
expect a compiler never to inline functions unless -Obloat (-O3 or
whatever) is specified, so it's useful to have a common syntax
signalling functions that the user wants to be inlined. The reason
register is stupid is that there's no tradeoff involved; keeping a
variable in a register is always preferred when possible. But inline
may be good or bad and usually the compiler can't make the decision
correctly.

BTW an interesting use of inline from the FFmpeg project is writing
functions with lots of conditionals that get optimized away at
compiletime. Something like:

inline int foo(..., int flag) { lots of conditionals depending on flag }
int bar0(...) { return foo(..., 0); }
int bar1(...) { return foo(..., 1); }

It's like nasty macro hacks but much cleaner. Something like this
might be useful in parts of BB too for compiletime code elimination.

Rich




More information about the busybox mailing list