Old compiler optimizations in installed headers

[Joseph Myers]

On Mon, 25 May 2015, Ondøej Bílka wrote:

> > I'd like to propose that:
> > 
> > (a) if an optimization could clearly be done in the compiler - if it only 
> > depends on the standard semantics of standard functions, or fully-defined 
> > semantics of glibc functions that it would be reasonable to encode into 
> > GCC, rather than e.g. generating calls to a glibc-internal function - then 
> > we should be wary of adding it to glibc's headers in the first place: in 
> > accordance with principles of GNU projects working together, it's better 
> > to add the optimization to GCC; and
> >
> I disagree for simple reason of cost. Its considerably easier to write a
> inline function that does transformation than to write equivalent gcc
> pass.

The first question should be to determine the right way to implement 
something rather than the quick way.  And I think the right way is 
generally compiler optimization - which (for example) allows for use in 
kernel space, for optimization based on the function semantics (e.g. as 
regards aliasing) rather than just the semantics of a particular 
implementation in a header, and for different expansions depending on 
whether the compiler thinks the code in question is hot or cold 
(information possibly obtained from profile feedback - much code is 
generally cold, so expansions that increase code size should only be used 
in those bits of code determined to be hot, which is information simply 
not available at all in the headers).

Then, if putting an optimization (or compiler bug workaround, etc.) in 
glibc's headers when a compiler approach would also be possible, it should 
always be accompanied by a comment pointing to the GCC bug report 
requesting the optimization, and the bug should have a comment pointing 
back to that glibc header comment and saying to inform the glibc 
developers when resolving the bug so they know to insert appropriate 
__GNUC_PREREQ conditionals in the header.

-- 
Joseph S. Myers
joseph@codesourcery.com