This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Old compiler optimizations in installed headers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Ondřej Bílka <neleai at seznam dot cz>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 28 May 2015 16:18:35 +0000
- Subject: Re: Old compiler optimizations in installed headers
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505221433160 dot 16611 at digraph dot polyomino dot org dot uk> <20150524225100 dot GA22541 at domone>
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