This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/11] Improve generic string routines
On 19/12/2016 16:16, Richard Henderson wrote:
> On 12/19/2016 08:15 AM, Joseph Myers wrote:
>> On Fri, 16 Dec 2016, Richard Henderson wrote:
>>
>>> I'll note that the comments regarding these tests are in fact out
>>> of date -- they speak of a number 0x7efefeff which does not appear
>>> (we use -0x01010101 or 0xfefefeff), and a test misfire which cannot
>>> actually occur (presumably because we changed algorithms).
>>
>> Another issue with this comment is bug 5806. Thus, patches removing that
>> comment should include [BZ #5806] in their ChangeLog entries, and once all
>> instances of the comment have been removed, that bug should be resolved as
>> FIXED with an appropriate milestone set.
>
> Oh how nice -- outstanding for 8 years.
>
>> * Missing spaces before '(', in lots of places in the patch series.
>
> Ug, yes. Too much recent work in code bases that prohibit this.
>
>> * Rather than hardcoding unsigned long int as the word type to use, it
>> would be better to have another sysdeps header where architectures can
>> choose the type to use for this purpose, so that ILP32 configurations with
>> 64-bit registers can use unsigned long long int instead. (E.g. there
>> aren't many MIPS-specific string functions, so MIPS n32 would benefit from
>> using 64-bit integers here.)
>
> Since my strcmp uses memcopy.h for MERGE, perhaps the op_t that's already
> defined in there? Or...
>
>> * Ondřej Bílka had patches doing similar things in May/June 2015, e.g.
>> <https://sourceware.org/ml/libc-alpha/2015-05/msg00882.html>
>> <https://sourceware.org/ml/libc-alpha/2015-05/msg00884.html>
>> <https://sourceware.org/ml/libc-alpha/2015-05/msg00881.html>
>> <https://sourceware.org/ml/libc-alpha/2015-06/msg00072.html> (these may
>> not be the latest versions of the relevant patches and may not constitute
>> a complete set of relevant patches; it's not very clear which of the
>> patches in patchwork are or are not superseded). I haven't compared the
>> approaches in detail to see if there is anything useful to take from those
>> old patches not covered in the present series.
>
> ... if we go with Ondrej's skeletons that defines its own type.
>
> Is there a preference for or against many little headers, like I was using, or
> a larger header using ifdefs to allow an architecture to override specific
> portions, like Ondrej was using?
>
As Joseph, I also prefer small headers since it usually requires less boiler
plate to override specific definitions.
> Given our recent-ish preference for avoiding #ifdef in favor of #if, I really
> don't know which is more preferable.
>
> The things that Ondrej does that I don't are (1) cater to cpus with unaligned
> accesses, (2) unroll loops and headers, (3) handle more routines. There are a
> lot of little-endian-only checks in his code and I'm not sure why it would have
> to be so.
I think all 3 more things Ondrej patches added are orthogonal to the
ones in you patchset and I think it would be more simpler to limit
the optimization and changes instead of drop a large one with all
the possible outlined ones on it.
>
> Perhaps I should look more closely at Ondrej's patches and see how easy it
> might be to apply my inline hppa asms...
>
>
> r~
>