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: [PATCH] Do not transform strchr into rawmemchr


On Thu, 17 Nov 2016, Zack Weinberg wrote:

> Regarding __builtin_strfoo versus strfoo, I _think_ an inline forward to
> __builtin_strfoo does something useful when either the name or the type
> signature of 'strfoo' doesn't match what the compiler expects.  So, for
> instance, we will want them in the covariance case as long as the C++
> compiler hasn't had its builtins updated to know that there are now two
> overloads of strwhatever -- but then they become unnecessary.  On the
> other hand, in the strchr/rawmemchr case, the basic prototype for strchr
> should be enough to clue the compiler that it knows what this function
> does, with no further prompting.  I could be wrong about this.
> 
> cc: Joseph: do you know whether my understanding is accurate?

Mapping strfoo to __builtin_strfoo may also be useful in the case where 
strfoo is not a C90 function (so the user may have used -std=c90 
-D_GNU_SOURCE, getting the declaration of strfoo but without it being 
built-in in the compiler).

In the strchr case, it's a C90 function so aside from inlines for C++ 
overloads mapping to __builtin_strchr should not be of use (if someone 
uses -fno-builtin or -ffreestanding there should be no expectation that 
headers need to try to optimize things anyway, and even the case where 
-std with feature test macros means the function is declared but not 
built-in is pretty marginal).

-- 
Joseph S. Myers
joseph@codesourcery.com


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