<div dir="ltr"><div>Hi David & James,</div><div><br></div><div class="gmail_quote"><div dir="ltr">On Sat, Jan 5, 2019 at 1:17 AM David Jones <<a href="mailto:david.jones@metrics.ca">david.jones@metrics.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">If we are considering an optimization to convert calls to memcmp into bcmp, then does it make sense to add an intrinsic for bcmp like there is for memcmp?  That way IR writers can express their requirements precisely: memcmp if you care about the direction of inequality, and bcmp if you do not.</div></blockquote><div><br></div><div>As mentioned in my answer to Hal above, I think the backend at least should be able to do this.</div><div><br></div><div>Then adding an intrinsic is only for for convenience, because if the backend can do the optimization automatically it's enough for the frontend to emit the attribute. For example, for a language that has a runtime which as a memeq/bcmp, the frontend could just emit the call site annotation. I have no strong opinion on whether the convenience justifies an intrinsic.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 12:34 PM James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This seems a somewhat odd and overcomplicated way to go about this.<div><br></div><div>Given that bcmp was required in POSIX until relatively recently, I will guess that almost all platforms support it already. From a quick check, glibc, freebsd, netbsd, newlib, and musl all seem to contain it. So, couldn't we just add bcmp to the runtime function list for those platforms which support it? And, add an optimization to translate a call to memcmp into bcmp if it exists?</div></div></blockquote></div></blockquote><div><br></div><div>That would indeed be much simpler, but this seems brittle to me. The approach you're suggesting works for us (google) because we fully control our environment, but I'm afraid it will not work for others. </div><div>For example, someone might distribute linux binaries built with LLVM to their users, but since there is nothing guaranteeing that bcmp is available on the user's libc, they won't be able to run it on their systems.</div><div>Is there a precedent for that approach ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Of course, it would then also be a good idea to go back to POSIX and present the performance numbers to make a case for why it was actually a quite valuable function and should be reinstated into the standard as well.<br></div></div></blockquote></div></blockquote><div><br></div><div>Indeed :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 3, 2019 at 4:30 AM Clement Courbet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Hi all,</div><div><br></div><div>We'd like to suggest <b>adding a -memeq-lib-function</b> flag to allow the user to specify a `<b>memeq()</b>` function to improve string equality check performance. </div><div><br></div><div>Right now, when llvm encounters a <b>string equality check</b>, e.g. `if (memcmp(a, b, s) == 0)`, it tries  to expand to an equality comparison if `s` is a small compile-time constant, and falls back on calling `memcmp()` else.</div><div><br></div><div>This is sub-optimal because memcmp has to compute much more than equality.</div><div>    </div><div>We propose adding a way for the user to specify a `memeq` library function (e.g. `-memeq-lib-function=user_memeq`) which will be called instead of `memcmp()` when the result of the memcmp call is only used for equality comparison.</div><div><br></div><div>`memeq` can be made much more efficient than `memcmp` because equality comparison is trivially parallel while lexicographic ordering has a chain dependency.</div></div><div><br></div><div>We measured an very large improvement of this approach on our internal codebase. A significant portion of this improvement comes from the stl, typically `std::string::operator==()`.</div><div><br></div><div>Note that this is a <b>backend-only change</b>. Because the c family of languages do not have a standard `memeq()` (posix used to have `bcmp()` but it was removed in 2001), c/c++ code cannot communicate the equality comparison semantics to the compiler.</div><div><br></div><div>We did not add an RTLIB entry for memeq because the user environment is not guaranteed to contain a `memeq()` function as the libc has no such concept.</div><div><br></div><div>If there is interest, we could also contribute our optimized `memeq` to compiler-rt.</div><div><br></div><div><div>A proof of concept patch for this for this RFC can be found here: <a href="https://reviews.llvm.org/D56248" target="_blank">https://reviews.llvm.org/D56248</a></div></div><div><br></div><div>Comments & suggestions welcome !</div><div>Thanks,</div><div><br></div><div>Clement</div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</blockquote></div>
</blockquote></div></div>