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

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>

If you need any help integrating with lit, or any changes made to
benchmark, please let me know.

On Sun, 29 Jul 2018, 00:34 Chandler Carruth via cfe-dev, <
cfe-dev at lists.llvm.org> wrote:
> 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
>>
> _______________________________________________
> 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/20180729/a7fad0e3/attachment.html>

Thank you very much for the feedback!

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.

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!

Kind regards,
Kirill Bobyrev

On Mon, Jul 30, 2018, 9:40 AM Dominic Hamon via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> If you need any help integrating with lit, or any changes made to
> benchmark, please let me know.
>
> On Sun, 29 Jul 2018, 00:34 Chandler Carruth via cfe-dev, <
> cfe-dev at lists.llvm.org> wrote:
>
>> 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
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> 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/20180802/c949753a/attachment-0001.html>