Renato Golin via llvm-dev
2021-Oct-07 21:05 UTC
[llvm-dev] Proposal: introduce dependency on abseil when building benchmarks
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/16e03214/attachment.html>
Mircea Trofin via llvm-dev
2021-Oct-07 22:59 UTC
[llvm-dev] Proposal: introduce dependency on abseil when building benchmarks
+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>