[llvm-dev] [PATCH] strlen -> strnlen optimization

[Philip Reames via llvm-dev]

On 02/07/2016 12:19 PM, Joerg Sonnenberger via llvm-dev wrote:
> On Sun, Feb 07, 2016 at 01:21:29PM -0500, Michael McConville via llvm-dev wrote:
>> Joerg Sonnenberger wrote:
>>> On Sat, Feb 06, 2016 at 11:05:14PM -0500, Michael McConville via llvm-dev wrote:
>>>> This addition converts strlen() calls to strnlen() when the result is
>>>> compared to a constant. For example, the following:
>>>>
>>>> strlen(s) < 5
>>>>
>>>> Becomes:
>>>>
>>>> strnlen(s, 5) < 5
>>>>
>>>> That way, we don't have to walk through the entire string. There is the
>>>> added overhead of maintaining a counter when using strnlen(), but I
>>>> thought I'd start with the general case. It may make sense to only use
>>>> this optimization with small constants. On the other hand, the impact of
>>>> the counter may be negligible in many or most cases due to
>>>> hardware-level optimizations.
>>> This is an optimisation I am very vary of two two reasons:
>>> (1) strnlen is only POSIX2008, so missing on many slightly older
>>> systems.
>> That's why we check whether it exists.
>>
>> glibc has had strnlen since 1996, OpenBSD since 2010, FreeBSD since
>> 2009, OS X since ~2010. I expect that the vast majority of Unix-like
>> systems have it. Regardless, I don't think this optimization does any
>> significant harm to systems that lack strnlen.
> Breaking correct code is the poster child of significant harm.
We have an existing mechanism for determining whether a given target 
platform has a particular common library function.  There is nothing new 
about the transform being proposed here.  This is a problem we know how 
to solve.

Philip