[PATCH] D31943: [Support] - Implemented zlib::StreamCompression class.

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 11 10:13:36 PDT 2017


The code in LLD, you mean? Ah - I'll leave that side to you, for sure. Not
sure what George has in mind for how this would fit/be used in LLD.

(For llvm-dwp the sections have no relocations, so it's totally applicable
there, but I don't expect to use that as the motivation for committing this
patch - but as a possible thing I could reuse the functionality for at some
point)

On Tue, Apr 11, 2017 at 10:07 AM Rui Ueyama <ruiu at google.com> wrote:

> You can indeed do that way, but the code to do that would look very
> different from the current code, because you need to apply relocations and
> pass it to zlib for each input section. Not sure if it's worth it.
>
> On Tue, Apr 11, 2017 at 9:59 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Tue, Apr 11, 2017 at 9:47 AM Rui Ueyama via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
> ruiu added a comment.
>
> I wonder why you want a streaming compression support to write compressed
> .debug sections. All you need is to call zlib's `compress2` only once for
> each section, no?
>
>
> Potentially to avoid having to manifest the entire output section in a
> single buffer in memory first (eg: if you're compressing 3 chunks from
> input objects together into the final output section - you can avoid the
> intermediate buffer/copying/etc, by passing the chunk from each input
> object in to a streaming compression device). At least that's what I'd use
> this for in llvm-dwp.
>
>
>
>
> https://reviews.llvm.org/D31943
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170411/5ee34500/attachment-0001.html>


More information about the llvm-commits mailing list