[llvm-dev] [RFC] Refactor llvm-dwp in to a library.

[David Blaikie via llvm-dev]

On Mon, Jun 21, 2021 at 6:28 PM Alexander Yermolovich <ayermolo at fb.com>
wrote:

> Hello David
>
> I haven't dug into llvm-dwp performance. What are some of the performance
> pain points that you know about?
>

Yeah - using LLVM's higher level abstractions for writing object files
(MCStreamer et, al) means that, as far as I recall, all the output ends up
buffered in memory before being written out - whereas, ideally, it'd be
streamed (memcpy to/from memory mapped files) from input file to output
file (potentially through streamed compression/decompression where possible
too - another layer of the MCStreamer abstractions that can add cost
(though I don't think I implemented support for compressing output in
llvm-dwp, though it'd be trivial to add because it's already supported in
MCStreamer (but that support does buffer the whole uncompressed and
compressed data... ))). Maybe some other things, but that's certainly the
top of my list.

- Dave


>
> Thank You
> Alex
> ------------------------------
> *From:* Alexander Yermolovich
> *Sent:* Monday, June 21, 2021 6:11 PM
> *To:* llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
> *Cc:* dblaikie at gmail.com <dblaikie at gmail.com>; Maksim Panchenko <
> maks at fb.com>
> *Subject:* [RFC] Refactor llvm-dwp in to a library.
>
> Hello
>
> I am working on adding support for bolt (
> https://github.com/facebookincubator/BOLT/tree/rebased) to write out DWP
> directly.  I want to re-use as much llvm-dwp functionality as possible.
> Plan is to move most of functionality that is now in llvm-dwp in to
> llvm/lib/DWP, with corresponding header file in llvm/include/llvm/DWP.
> In the header files have
> getContributionIndex
> handleSection
> parseCompileUnitHeader
> writeStringsAndOffsets
> getCUIdentifiers
> buildDuplicateError
> writeIndex
>
> For structs that are passed around define in the header also.
> UnitIndexEntry
> CompileUnitHeader
> CompileUnitIdentifiers
>
>
> Thought I would solicit opinions before I dive too deep into this.
>
> Thank You
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210621/3631556d/attachment.html>