[llvm-dev] [RFC] Introduce Dump Accumulator

[Mircea Trofin via llvm-dev]

No disagreement there. We illustrate with scenarios we have only because we
can speak confidently about them, and the hope was they may resonate with
others' (we didn't expected them to be sufficient motivation, had they been
ours alone). If it turned out that no one had similar scenarios, or the
design was too narrow, we would have sought an outside-llvm alternative,
for all the reasons you mention. In this case, RemarksEmitter seems to
suggest related problems were addressed already.

On Thu, Aug 6, 2020 at 9:17 AM Renato Golin <rengolin at gmail.com> wrote:

> On Thu, 6 Aug 2020 at 16:49, Mircea Trofin <mtrofin at google.com> wrote:
> > At a high level, you are right, the 2 alternatives are similar, but the
> devil is in the details. The build system (basel-based) is hermetic, and
> needs to be aware of all such extra files, and have a separate rule to copy
> and concatenate them. This solution turned out to be much cleaner.
>
> Cleaner to your build system is not necessarily cleaner to LLVM and
> all its users (downstream and upstream) and sub-projects.
>
> What I'm trying to avoid is a custom-built solution injecting random
> sections in the ELF binary to fix a problem that a specific build
> system has for a specific project. That doesn't scale.
>
> Like Hal, I'm trying to get you to use existing solutions in LLVM to
> suit your needs, as the cost of keeping dangling features (ones used
> by a single project) in a code as large as LLVM usually doesn't pay
> off.
>
> Even if that makes your build system slightly worse, the benefit of
> not adding bespoke features, to all LLVM users (including you), is
> still very much positive.
>
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200806/c7c3405f/attachment.html>