<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 8:10 AM dominic hamon <<a href="mailto:dominic@google.com">dominic@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"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 4:06 PM Mircea Trofin <<a href="mailto:mtrofin@google.com" target="_blank">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"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 9:37 PM Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@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"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 9:26 PM Mircea Trofin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 8:57 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@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"><div dir="ltr">On Thu, Sep 30, 2021 at 10:08 AM Mircea Trofin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">TL;DR; When either of LLVM_BUILD_BENCHMARKS or LIBCXX_INCLUDE_BENCHMARKS are enabled, as well as for llvm-test-suite, a dependency to abseil would either be auto-downloaded by the build system, or need to be user-specifiable, or provided in the source tree.</div></blockquote><div><br></div><div>Could you please elaborate on which of these approaches will be used for LLVM? How will this affect regular LLVM developers?</div></div></div></blockquote><div>Assuming regular LLVM developers means developers that don't enable LLVM_BUILD_BENCHMARKS, nor LIBCXX_INCLUDE_BENCHMARKS, then they are not affected.</div><div><br></div><div>The current PR in "benchmarks" upstream is set up so that it will either download the abseil dependency at build time, or, if the location of abseil is specified via a cmake flag, then it uses that one (which covers the last 2 options). I don't know if the first option is acceptable by those that enable LLVM_BUILD_BENCHMARKS / LIBCXX_INCLUDE_BENCHMARKS, and this is something I'm hoping to discover with this thread. If it is acceptable, it's a transparent option, so it won't directly impact those users either.</div></div></div></blockquote><div><br></div><div>What should we expect in terms of ability to benchmark LLVM on various platforms / OSes? It seems like we will tie ourselves to Abseil, and I don't know anything about how their compatibility matrix compares to LLVM one? (and if it will continue being true in the foreseeable future?)</div></div></div></blockquote><div><br></div><div>The goal isn't for benchmark to change its dependency matrix due to the new dependency ( <a class="gmail_plusreply" id="gmail-m_-2054782327389384234gmail-m_7217551154604648961gmail-plusReplyChip-2" href="mailto:dominic@google.com" target="_blank">+dominic hamon</a> , please correct me). So from the perspective of LLVM, this doesn't change anything. Granted, there is now a strictly higher probability for breaking changes, if abseil decides to change its support matrix and break benchmark, and thus affect the latter's LLVM users.</div><div><br></div></div></div></blockquote><div><br></div><div>We're reducing our dependency matrix (dropping support for older compilers/OSs) as part of the adoption of abseil. This may impact llvm if there was an expectation to continue to benchmark against those older compilers/OSs.</div></div></div></blockquote><div>Isn't that support drop part of usual business, though (i.e. drop after TLS)?</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 class="gmail_quote"><div><br></div><div><a href="https://google.github.io/benchmark/dependencies.html" target="_blank">https://google.github.io/benchmark/dependencies.html</a> is the current policy but with abseil that "best effort" support will no longer be viable.<br></div><div> </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 class="gmail_quote"><div></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 class="gmail_quote"><div><br></div><div>Thanks,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </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 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 class="gmail_quote"><div><br></div><div>----</div><div><br></div><div>This is truly unrelated, but I have a lot of feelings about this, and I will use this opportunity to inappropriately complain that the benchmarks library has been spamming me with cmake warnings about std::regex for years: <a href="https://bugs.llvm.org/show_bug.cgi?id=38874" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=38874</a> The CMake step really ought to be warning-clean.</div></div></div></blockquote><div>Ack. Added an issue on the project side: <a href="https://github.com/google/benchmark/issues/1236" target="_blank">https://github.com/google/benchmark/issues/1236</a> (maybe it has better visibility)</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>