<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 6, 2015 at 11:47 AM, Dmitri Gribenko <span dir="ltr"><<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="">On Fri, Mar 6, 2015 at 11:29 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
><br>
> On Fri, Mar 6, 2015 at 10:21 AM, <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
>><br>
>> Almost none of my benchmarking machines can initiate outgoing connections,<br>
>> so I'd need to download/checkout the Google 'benchmark' library manually.<br>
>> Can you please add some comments about exactly what should be retrieved, and<br>
>> where it should be put.<br>
><br>
><br>
> The entire thing seems odd.<br>
><br>
> I would much rather just have the benchmark code live in some utility place<br>
> in one of the repositories. For example, we keep gtest in utils/unittest in<br>
> the LLVM repository. I wonder if we could check the benchmark stuff into<br>
> utils/benchmark, and add it to CMake normally.<br>
><br>
> Then the benchmarks can be built normally with CMake (or Makefiles) and LIT<br>
> can just be responsible for actually running them.<br>
><br>
> This would make the benchmarks unavailable from a stand-alone build of<br>
> libc++ but that seems a not-terrible tradeoff.<br>
<br>
</div></div>+1 from me.  It would be great to have a benchmarking framework<br>
in-tree so that other projects could use it.  For example, we could<br>
have latency tests for Clang code completion or re-parsing with<br>
implicit PCH.</blockquote></div><br>Eric reminded me that I may have led to this design. Sorry for that if so...</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think the concern I had was that we don't currently have any unusually licensed stuff in the libc++ tree, and adding it might be problematic. Keeping the license of libc++ super clear and explicit is really important because it is a runtime library and can be used in even more diverse contexts than the rest of LLVM.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I had originally thought that we might not want to re-use an existing benchmarking framework, but I can also see lots of good reasons to re-use an existing framework.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My hope with the suggestion of keeping the benchmarking framework in the core LLVM repository is that it would make it much more clear that none of the functionality in libc++ would have anything to do with it, only benchmarks. The benchmarks themselves of course could always live in the libc++ repository and be built with an explicitly specified copy of the benchmark framework if libc++ were being used outside of an LLVM checkout.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Hopefully that clarifies some of why it might be useful to have *some* levels of separation between the project and the benchmarking stuff...</div></div>