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: glibc 2.23 release blocker: ABI for AArch64 string inlines.



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 [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.
> 

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
usercases.

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.


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