[llvm-dev] [cfe-dev] Proposal: pull benchmark library to the LLVM main repository

[Chandler Carruth via llvm-dev]

I'm happy to have this in the main LLVM repositiory.

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.

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.

On Sat, Jul 28, 2018 at 4:04 PM Dean Michael Berris via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> I’m a huge fan of having more benchmarks, and support this proposal.
>
> On Sat, 28 Jul 2018 at 2:16 am, Kirill Bobyrev via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Kind regards,
>> Kirill Bobyrev
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> --
> Dean
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180728/c155039c/attachment.html>