[llvm-dev] Proposal: introduce dependency on abseil when building benchmarks

[Mircea Trofin via llvm-dev]

+more folks based on recent updates to either of the 3 `google/benchmark
<http://github.com/google/benchmark>` (`benchmark` for short) copies in
LLVM. Apologies if I missed anyone.

*The summary is*: in the `benchmark` repo we're considering adopting
abseil. For LLVM, if we're OK with continuing to maintain our own fork(s)
of the `benchmark` project and opportunistically patch them as needed, the
abseil dependency upstream should have no real impact[*].

That dependency does impact us in LLVM, should we want to have a more
automated way for depending on `benchmark`, such as periodic pulls. The
abseil support guarantees may not cover sufficiently well the scenarios in
which folks build and run these kinds of benchmarks. This thread has more
details.

====
[*]Short of patches upstream that are so heavily dependent on abseil that
porting them to the forks in llvm would prove super-challenging. Abseil
would primarily used at the periphery of the project, e.g flags, for string
manipulation, and concurrency, so probability of such challenging changes
is low (but I'm biased).

On Thu, Oct 7, 2021 at 2:05 PM Renato Golin <rengolin at gmail.com> wrote:

> On Thu, 7 Oct 2021 at 20:51, James Y Knight <jyknight at google.com> wrote:
>
>> The plan should simply be: submit patches if it's broken on an
>> architecture or OS that someone cares about.
>>
>
> This only works if the people who currently run those benchmarks in LLVM
> can continue running them _before_ submitting patches.
>
> Old versions of the toolchains is a different matter, however -- Abseil's
>> general promise is to support an old release of a C++ compiler for 5 years
>> after it has been superseded by a newer version. And supporting old
>> compilers tends to be a significant burden, so unlike porting to a new CPU
>> or OS, *that* isn't simply a "patches welcome" situation -- there would
>> have to be a compelling case made that preserving support for an compiler
>> older than that was important enough to be worth the hassle.
>>
>
> Because it supports clang, it should be fine.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/7a345070/attachment.html>