llvm dev - Jun 2021 - [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/20210622/6822dc74/attachment-0001.html>

I'm OK-ish with this, though I will warn you, llvm-dwp is not, in my
opinion (as the author of it), the best foundation for this sort of thing.
In particular it uses significantly more memory (& probably CPU) than
gold's dwp tool - building more things on top of this before addressing
some of those scalability issues will build more technical debt that'll
need to be paid down at some point. If you plan to use this in a production
use case, I'd strongly encourage you to invest some time in improvements to
llvm-dwp's scalability first, to create a better foundation to build on top
of. I'm happy to help with/advise on that work.

On Mon, Jun 21, 2021 at 6:11 PM Alexander Yermolovich <ayermolo at fb.com>
wrote:
> 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/d3049aed/attachment.html>

Hello David

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

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/20210622/2b0f0653/attachment.html>