<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Scott,<div class=""><br class=""></div><div class="">Usually patches are sent to llvm-commits (unless I missed a specific reason to send this patch to llvm-dev instead), see: <a href="http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch" class="">http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch</a></div><div class="">(we also have a phabricator instance: <a href="http://llvm.org/docs/Phabricator.html" class="">http://llvm.org/docs/Phabricator.html</a></div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 12, 2017, at 6:52 PM, Scott Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Sorry, that last patch didn't handle endianness very well. Here's an updated patch that uses llvm::support::endian. I assume unaligned input, which is safer. I have no idea whether one can expect aligned input to this function. It also wouldn't take much to process the first <=3 bytes one at a time, then blast through assuming aligned reads, and then finish up with another <=3 bytes. Let me know if you prefer that.<br class=""><br class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Apr 12, 2017 at 8:49 PM, Scott Smith <span dir="ltr" class=""><<a href="mailto:scott.smith@purestorage.com" target="_blank" class="">scott.smith@purestorage.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class=""><div class="">Lldb relies heavily on crc when loading shared libraries. The existing implementation is quite slow as it computes a byte at a time, creating a long dependency chain.<br class=""><br class=""></div>Unfortunately the polynomial is not the same as the one implemented by x86 processors in SSE 4.2, but there's another way to make it faster by using more lookup tables.<br class=""><br class=""></div>Zlib implements this, but rather than require zlib, I instead added the relevant code to compute four bytes at a time in parallel.<br class=""><br class=""></div>A separate patch changes lldb to rely on JamCRC instead of its own implementation. This patch improves the performance, which brings my test (starting lldb, breaking at main) from 47 seconds down to 36 seconds.<br class=""><br class=""></div>
</blockquote></div><br class=""></div>
<span id="cid:5B083C25-303C-4643-AC3F-5E2CDDEDB2DF"><jamcrc.patch></span>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>