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

[Mircea Trofin via llvm-dev]

*<Fixed an email address I copied incorrectly>*

On Thu, Oct 7, 2021 at 3:59 PM Mircea Trofin <mtrofin at google.com> wrote:

> +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/82c02ba6/attachment.html>