This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.23 release blocker: ABI for AArch64 string inlines.
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, 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 13:42:22 +0000
- Subject: Re: glibc 2.23 release blocker: ABI for AArch64 string inlines.
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <56C49BDC dot 8040309 at redhat dot com>,<56C4B53E dot 2090803 at linaro dot org>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
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 [1] I think it is the right thing at least to
> correct the ABI issue.
Yes.
> 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.
Wilco