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 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?
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.
Perhaps I should look more closely at Ondrej's patches and see how easy it
might be to apply my inline hppa asms...
r~