This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Header inlines.


On Thu, 14 May 2015, Ondřej Bílka wrote:

> > Did the discussion involving 
> > <https://sourceware.org/ml/libc-alpha/2013-01/msg00157.html> and 
> > <https://sourceware.org/ml/libc-alpha/2013-01/msg00270.html> reach any 
> > wiki-documented consensus regarding what compiler versions it's worth 
> > having any optimizations for in the headers?
> > 
> These aren't too related to this problem, there is barely any discussion
> about performance, its mostly about support.

It seems directly related.  
<https://sourceware.org/ml/libc-alpha/2013-01/msg00270.html> has two 
paragraphs about optimizations in headers and not regressing such support 
"just in the name of generic simplification".

> I would use rule that if user doesn't care about performance by using
> obsolete gcc that generates slower code why should we care?

Well, maybe we should say that the optimizations for GCC < 4.1 (say) 
aren't significant enough to be worth the complexity of keeping (in 
headers not shared with gnulib) - though you still need to export all the 
old ABIs exported by string-inlines.c (they could be conditioned 
SHLIB_COMPAT so new architectures don't get them, however).  But such a 
change needs consensus.

> Also as I said before removing many of these would improve performance
> as they are obsolete and libcall is faster.

These are generally about optimizing cases of e.g. constant arguments for 
old compilers that didn't have such optimizations themselves.

-- 
Joseph S. Myers
joseph@codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]