<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 7, 2016 at 12:19 PM, Joerg Sonnenberger via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Sun, Feb 07, 2016 at 01:21:29PM -0500, Michael McConville via llvm-dev wrote:<br>
> Joerg Sonnenberger wrote:<br>
> > On Sat, Feb 06, 2016 at 11:05:14PM -0500, Michael McConville via llvm-dev wrote:<br>
> > > This addition converts strlen() calls to strnlen() when the result is<br>
> > > compared to a constant. For example, the following:<br>
> > ><br>
> > > strlen(s) < 5<br>
> > ><br>
> > > Becomes:<br>
> > ><br>
> > > strnlen(s, 5) < 5<br>
> > ><br>
> > > That way, we don't have to walk through the entire string. There is the<br>
> > > added overhead of maintaining a counter when using strnlen(), but I<br>
> > > thought I'd start with the general case. It may make sense to only use<br>
> > > this optimization with small constants. On the other hand, the impact of<br>
> > > the counter may be negligible in many or most cases due to<br>
> > > hardware-level optimizations.<br>
> ><br>
> > This is an optimisation I am very vary of two two reasons:<br>
> > (1) strnlen is only POSIX2008, so missing on many slightly older<br>
> > systems.<br>
><br>
> That's why we check whether it exists.<br>
><br>
> glibc has had strnlen since 1996, OpenBSD since 2010, FreeBSD since<br>
> 2009, OS X since ~2010. I expect that the vast majority of Unix-like<br>
> systems have it. Regardless, I don't think this optimization does any<br>
> significant harm to systems that lack strnlen.<br>
<br>
</span>Breaking correct code is the poster child of significant harm.<br></blockquote><div><br></div><div>This concern is important but is within LLVM's realm to handle.  If we do not believe the target has strnlen, then TLI should return false for TLI->has(LibFunc::strnlen).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> > (2) I do believe that the counting is quite harmful to the performance.<br>
><br>
> I'll benchmark. If we limit the optimization to cases where the constant<br>
> is (for example) < 20, a small performance hit from the counter may not<br>
> matter.<br>
><br>
> > Additionally, I wouldn't be surprised if many systems don't consider<br>
> > strnlen to be the fast path, so it would be even worse than using e.g.<br>
> > memchr for this.<br>
><br>
> The strnlen implementations I've looked at don't seem much different<br>
> from their strlen counterparts in the common libc's I looked at. For<br>
> example, glibc has asm implementations of both for common platforms.<br>
> FreeBSD only has asm implementations of strlen, but those are only for<br>
> ARM and MIPS. OpenBSD doesn't use asm for either. I wouldn't be<br>
> surprised if the extremely simple nature of the functions means that asm<br>
> implementations aren't noticeably faster.<br>
<br>
</span>I'm a bit surprised by FreeBSD, since even on amd64 the trivial lowering<br>
is almost always quite a bit slower than optimized versions...<br>
<br>
Joerg<br>
<div class=""><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>