[PATCH] D20433: [ELF] - Lazy initialization of MergeInputSection class internals.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Thu May 19 08:45:08 PDT 2016


On Thu, May 19, 2016 at 8:40 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> grimar added a comment.
>
> In http://reviews.llvm.org/D20433#434391, @ruiu wrote:
>
> > I think this change makes sense, but in this design uncompressing
> sections would be inevitably serialized because it uncompresses sections
> during section garbage collection and section writing. I'm wondering if
> there's a way to parallelize it. (You don't really have to parallelize it
> at this point, but I'm thinking about the design that allows us to
> parallelize it easily by rewriting a for-loop with a parallel_for)
> >
> > If there is no GC, we can uncompress all input sections after the name
> resolution is complete and before Writer::write(). We could simply visit
> all input sections and uncompress them if compressed.
> >
> > If GC is present, the situation becomes a bit tricky because we are
> using getRangeAndSize() in MarkLive.cpp to set live bits of pieces of input
> sections to true. However, we don't really need any section contents in GC;
> it just says that "a piece of data at this offset needs to be handled as
> live." Since we do not merge data at this point, we can still do without
> reading the section contents. Here's the observation.
> >
> > - Until Writer::write(), no one needs section contents.
> > - MergeInputSection only need to know which offsets are live during GC.
> > - We could uncompress all input sections in parallel whose live bit is
> on.
> >
> >   So I think there's a room to improve this patch.
>
>
> Yap, that is true. So I would start from solving the step 2 (know live
> offsets during GC) first for this patch, I guess.
>

Yes. And it might improve performance even in the normal use case (without
section compression) because that change would be to avoid reading section
contents at all if the section is going to be gc'ed.

I`ll try to improve it on all fronts though. Thanks for sharing ideas.
>
>
> http://reviews.llvm.org/D20433
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160519/7e643b5b/attachment.html>


More information about the llvm-commits mailing list