<div dir="ltr"><i><Fixed an email address I copied incorrectly></i></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 3:59 PM Mircea Trofin <<a href="mailto:mtrofin@google.com">mtrofin@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+more folks based on recent updates to either of the 3 `<a href="http://github.com/google/benchmark" target="_blank">google/benchmark</a>` (`benchmark` for short) copies in LLVM. Apologies if I missed anyone.<br><div><br></div><div><b>The summary is</b>: 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[*].</div><div><br></div><div>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.</div><div><br></div><div>====</div><div>[*]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).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 2:05 PM Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, 7 Oct 2021 at 20:51, James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">The plan should simply be: submit patches if it's broken on an architecture or OS that someone cares about.<br></div></div></blockquote><div><br></div><div>This only works if the people who currently run those benchmarks in LLVM can continue running them _before_ submitting patches.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div>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, <i>that</i> 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.</div></div></div></blockquote><div><br></div><div>Because it supports clang, it should be fine. </div></div></div>
</blockquote></div>
</blockquote></div>