<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>Over the last few days I've been looking into pulling the benchmark library to LLVM main repository as proposed before. I submitted a patch for suppressing warnings in benchmark library itself which prevented it from compiling in LLVM tree (due to enabled -Werror) and managed to build it in-tree.</div><div><br></div><div>However, I have found that cxx-benchmarks target (containing all libc++ benchmarks) is not buildable for a while. That fact and my experience of build failures when latest Clang is used to compile the project give me an impression that libc++ benchmarks are not frequently used (e.g. continuously run by buildbots). There are multiple commits in which cxx-benchmarks are not buildable, the one that is most likely causing the issue would be <a href="https://reviews.llvm.org/rL338103">https://reviews.llvm.org/rL338103</a>. Another complication is that libc++ can be built out-of-tree and it's possible to pull gtest (with no fixed version) from GitHub using ExternalProject_Add in one of the configurations. Also, libc++ seems to be capable of building benchmark library in two different configurations within the same build which probably means that some libc++-specific code would still end up in libc++ even if google/benchmark is pulled out of that repository (and also we would have to treat benchmark the same way gtest is handled for out-of-tree builds).</div><div><br></div><div>I was willing to reach out to the community and ask for more feedback on the following actions. The possible solutions are:</div><div><br></div><div>* Pull benchmark library into LLVM core repository without affecting libc++ at all (and introducing another copy of the library). We already have two distinct benchmark copies as mentioned before and I personally am not happy with introducing another one, but libc++ out-of-tree builds and specific requirements complicate things. libc++ also seems to have buildbots for out-of-tree builds which might be different from the "standard" LLVM workflow.</div><div>* See if the benchmark build can be fixed and handle benchmark similarly to gtest for out-of-tree libc++ builds. While this approach looks *correct* to me, I don't know if many users rely on building libc++ out-of-tree *and* testing it (and also potentially running benchmarks), e.g. the version of gtest downloaded from Github is pulled from master branch, which gives me an impression that this option is not frequently used (otherwise the version would probably be fixed for stability). It would also be harder to execute.</div><div>* Execute the first plan by introducing another copy in the LLVM core repository, then migrate libc++ to the LLVM's benchmark copy if the maintainers of libc++ are in favor. This seems both easier and still "correct" to me.</div><div><br></div><div>Since libc++ is currently the only user of benchmark library and I might miss some details, I wanted to see if anyone actively developing it could comment on that. I would also like to hear what the others think should be done to introduce benchmark library to the whole LLVM source tree, because I can't figure out what would be the best series of actions.</div><div><br></div><div>Also, is running benchmarks continuously something the community would be happy about in the long run?</div><div><br></div><div>Kind regards,</div><div>Kirill Bobyrev</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 2, 2018 at 10:22 AM Kirill Bobyrev <<a href="mailto:kbobyrev.lists@gmail.com">kbobyrev.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Thank you very much for the feedback!<div dir="auto"><br></div><div dir="auto">What Chandler said about test-suite totally makes sense to me since it's also excluded from LLVM git monorepo. I will try to land benchmark library to LLVM core repo and update it to the latest version.</div><div dir="auto"><br></div><div dir="auto">I have not been doing much CMake/project structure before, but I'll start looking into that next week. I'll reach out to Dominic if anything goes wrong, thank you for offering assistance!</div><div dir="auto"><br></div>Kind regards,</div><div dir="auto">Kirill Bobyrev<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon, Jul 30, 2018, 9:40 AM Dominic Hamon via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">If you need any help integrating with lit, or any changes made to benchmark, please let me know.</div><br><div class="gmail_quote"><div dir="ltr">On Sun, 29 Jul 2018, 00:34 Chandler Carruth via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm happy to have this in the main LLVM repositiory.<div><br></div><div>The version in the test suite should likely stay there because the test suite should be buildable w/o LLVM itself -- it is largely a distinct thing. We re-use lit, but not much else from LLVM, and we wouldn't want to install the benchmark library the way we do lit.</div><div><br></div><div>One interesting point: we should have some way of running the in-tree benchmarks, likely with lit, much like we currently allow running unittests with lit. May be something you want to think about.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jul 28, 2018 at 4:04 PM Dean Michael Berris via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">I’m a huge fan of having more benchmarks, and support this proposal.</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, 28 Jul 2018 at 2:16 am, Kirill Bobyrev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As a part of upcoming new Clangd symbol index implementation, we would like to start support benchmarks of different Clangd pieces, such as index queries and code completion.</div><div><br></div><div>There are already two projects in the LLVM tree using google/benchmark library while keeping its source code in-tree: libcxx (libcxx/utils/google-benchmark) and test-suite (test-suite/MicroBenchmarks/libs/benchmark-1.3.0). Storing another copy of benchmark library sources in clang-tools-extra would be unreasonable. We already have google test library in LLVM tree (llvm/utils/unittest/googletest) and it is used across all other subprojects, which looks to be very similar to the benchmark library in terms of reusing it across the projects. I would like to know if putting benchmark library along with googletest would be the best option. At the same time, benchmark library could be updated to the newer version (1.4.1) in the process of pulling it to the main LLVM repository.</div><div><br></div><div>It would be great to get feedback on whether this proposal looks reasonable to the LLVM Community and having benchmark in the llvm/ repository would be the best solution to the described problem.</div><div><div><br></div><div>Kind regards,</div><div>Kirill Bobyrev</div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="m_-6772532364931936547m_3592730165253207975m_2354721595055415524m_-5259507041924548492gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Dean</div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div></div>
</blockquote></div></div>