On Sat, Sep 20, 2014 at 11:26 AM, Dan Liew <dan at su-root.co.uk> wrote:> On 18 September 2014 16:59, Reid Kleckner <rnk at google.com> wrote: > > I also want to point out that there is prior art for bundling these > types of > > single-source-file utility libraries in lib/Support. We have MD5.cpp, > > ConvertUTF.cpp, and reg*.c implementing various bits of functionality. > > Adding a miniz.c doesn't seem like that big of a deal. > > I should of taken a look at miniz first! It is pretty small. I guess > provided > > 1.The library code is properly namespaced to prevent symbol clashes > for LLVM clients that already use miniz directly or indirectly. > 2. Someone takes ownership over this code inside LLVM > > then this is probably fine. Sorry I have a bit of knee-jerk reaction > where I hear about embedding libraries because it's caused me problems > in the past. > > Would the aim be to use miniz as a fallback if libz isn't available or > we want always use miniz? > > I'll submit the patch that started to be developed in this thread to > llvm-commits for review anyway as it might be useful to have it in > trunk.I would much rather have consistent and predictable behavior by using the bundled source code on every platform. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/efeb3a52/attachment.html>
> I would much rather have consistent and predictable behavior by using the > bundled source code on every platform.That makes sense. Do you plan to make the switch soon? If so there is probably no point reviewing/committing the patch that I and Johannes were working because it would have to be removed for integration of miniz. That's assuming you don't want to provide an option to use the system libz library. This probably isn't a great idea though, the only use I can see is benchmarking libz Vs miniz which is quite a small use case which I don't think justifies over complicating the code.
On Sep 20, 2014, at 11:37 AM, Chandler Carruth <chandlerc at google.com> wrote:> > On Sat, Sep 20, 2014 at 11:26 AM, Dan Liew <dan at su-root.co.uk> wrote: > On 18 September 2014 16:59, Reid Kleckner <rnk at google.com> wrote: > > I also want to point out that there is prior art for bundling these types of > > single-source-file utility libraries in lib/Support. We have MD5.cpp, > > ConvertUTF.cpp, and reg*.c implementing various bits of functionality. > > Adding a miniz.c doesn't seem like that big of a deal. > > I should of taken a look at miniz first! It is pretty small. I guess provided > > 1.The library code is properly namespaced to prevent symbol clashes > for LLVM clients that already use miniz directly or indirectly. > 2. Someone takes ownership over this code inside LLVM > > then this is probably fine. Sorry I have a bit of knee-jerk reaction > where I hear about embedding libraries because it's caused me problems > in the past. > > Would the aim be to use miniz as a fallback if libz isn't available or > we want always use miniz? > > I'll submit the patch that started to be developed in this thread to > llvm-commits for review anyway as it might be useful to have it in > trunk. > > I would much rather have consistent and predictable behavior by using the bundled source code on every platform.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. ----------------------------------------- Alex Rosenberg Manager, Platform Architecture Sony Computer Entertainment America, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140922/15eff504/attachment.html>
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/d65f83b3/attachment.html>