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] |
On 19 Apr 2016 17:27, Adhemerval Zanella wrote: > On 19-04-2016 14:57, Mike Frysinger wrote: > > On 25 Feb 2016 13:04, Wilco Dijkstra wrote: > >> Remove the strchr (s, '\0') to rawmemchr optimization as using rawmemchr is > >> a bad idea - I have a patch to add strchr (s, '\0') -> strlen to GCC7. > >> Like strchr (s, '\0'), rawmemchr (s, '\0') appears a common idiom for finding > >> the end of a string, however it is not the most efficient way of doing so. > >> Strlen is a simpler operation which is significantly faster on larger inputs > >> (eg. on x86 strlen is 50% faster than rawmemchr on strings of 1KB). > > > > will there be a change in GCC to also detect rawmemchr(s,'\0') ? > > > > even then, since this optimization isn't showing up until GCC7, shouldn't > > we keep some logic here ? i.e. transform strchr/rawmemchr(s, '\0') into > > strlen before falling back ? > > Personally I am not very found on the string2.h header and its intrinsic logic, > which contains optimization logic that might not be true depending of the > architecture string optimization. > > Also for the specific optimization does we really need to keep pushing for > these specific inline implementations? I would prefer a much simple string2.h > header than a convoluted one we have today. i don't have a real opinion on keeping it or just tossing the whole thing out. but if we keep it, i think we should be adding the bits that make sense (like my question above) rather than half-assing it. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |