[LLVMdev] proposal to avoid zlib dependency.

[Daniel Berlin]

There are also alternative implementations of deflate that are much faster
on various processors, but produce zlib compatible compression  (
http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/ia-deflate-compression-paper.pdf,
et al).  As chandler said, doubt it's worth going down this path.
If we have speed issues, zlib is not the way you want to go.

On Tue Sep 23 2014 at 9:05:52 AM Alex Rosenberg <alexr at leftfield.org> wrote:

> On Sep 23, 2014, at 7:42 AM, Jim Grosbach <grosbach at apple.com> wrote:
>
>
> On Sep 23, 2014, at 1:29 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
>
> On Mon, Sep 22, 2014 at 9:38 PM, Alex Rosenberg <alexr at leftfield.org>
> wrote:
>
>> Is your answer the same if we're talking about an asm version of zlib
>> that's faster than the compiled version? Because that's a thing.
>
>
> If zlib is our bottleneck... wow we have bigger issues.
>
> And as we work on a compiler, I kinda hope we can produce a reasonable
> blob of asm in most cases. If not, we should probably get on that.
>
>
> Dang it. Beaten to the punch. I was just going to ask for a bug report
> that we apparently generate suboptimal code for that. :)
>
> Taking my trolling hat back off, I actually am interested in whether it’s
> reasonable for the compiler to do significantly better here (and on other
> similar kinds of code). Alex, can you elaborate a bit?
>
>
> Zlib has been written in asm a few times over, just check the distribution.
>
> I haven't looked too closely at the code, but from my recollection of
> someone in my team writing a SPU version, it's pretty much a set of
> transforms that if a compiler could do them would be considered "heroic
> optimizations" and likely not the sort of thing we'd put in LLVM.
>
> Alex
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/25593123/attachment.html>