This is the mail archive of the
mailing list for the glibc project.
Re: glibc 2.23 release blocker: ABI for AArch64 string inlines.
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Thu, 18 Feb 2016 17:59:20 -0200
- Subject: Re: glibc 2.23 release blocker: ABI for AArch64 string inlines.
- Authentication-results: sourceware.org; auth=none
- References: <56C49BDC dot 8040309 at redhat dot com> <56C4B53E dot 2090803 at linaro dot org> <AM3PR08MB0088F6B08CF82E1331A5704E83AF0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com>
On 18-02-2016 11:42, Wilco Dijkstra wrote:
> Adhemerval Zanella wrote:
>> On 17-02-2016 14:12, Carlos O'Donell wrote:
>>> Wilco, H.J.,
>>> What's the status of the last 2.23 blocker?
>>> It seems like H.J's alternative proposal is acceptable to Wilco.
>>> Do we just need some more review to make sure this what we want?
>>> As an ABI issue it's important we get this right.
>> If you are referring to  I think it is the right thing at least to
>> correct the ABI issue.
>> I am not really convinced if there is any hard performance requirement
>> for any of the define usage inside glibc. In fact I think it would be
>> cleaner if we remove all its internal usage and evaluate if the
>> algorithm performance gains (if any) is indeed meaningful to add such
>> complexity. However this is a future possible cleanup.
> It looks like the only cases where there may be a reasonable performance
> gain are the uses in crypt/*. A lot of the others seem more like bug fixes for
> illegal unaligned accesses rather than for performance gains.
> We could remove all existing internal uses in the future but that would mean
> never adding new uses, eg. fast generic string functions using unaligned
> accesses like various assembler implementations.
Even for crypt/* I do not see a compelling reason, my understanding it these
function have quite limited scope (password hashing) and people usually
turn to more optimized implementation (openssl, etc.) for performance
Also for fast implementation using unaligned accesses I think we can evaluate
and if it is the case add again the define internally. My idea is just to cleanup
up 'optimized' implementation where the gains are very limited and which the
unaligned access only adds more code complexity.