Re: [PATCH 00/11] Improve generic string routines

[Richard Henderson <rth at twiddle dot net>]

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~