[llvm-dev] Consolidating copies of google/benchmark in the repo (Was: Proposal: introduce dependency on abseil when building benchmarks)

Mircea Trofin via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 25 08:18:22 PDT 2021


Circling back from https://reviews.llvm.org/D112012
<https://reviews.llvm.org/D112012#3078815> - would having google/benchmark
under a new `llvm-project/third-party` work, instead of
`llvm-project/llvm/utils`? (rationale there, TL;DR; libcxx (and other
runtimes) wants to detach itself from anything `llvm-project/llvm`)

On Wed, Oct 13, 2021 at 10:28 PM Mircea Trofin <mtrofin at google.com> wrote:

>
>
> On Wed, Oct 13, 2021 at 6:45 AM Renato Golin <rengolin at gmail.com> wrote:
>
>> On Tue, 12 Oct 2021 at 21:20, Mircea Trofin <mtrofin at google.com> wrote:
>>
>>> One thing that does come to mind, llvm-test-suite can be cloned
>>> separately from llvm-project/llvm. We'd need to point to llvm (or just
>>> llvm/utils/benchmark), and require that it be available on bots, for
>>> example. Does that cause an issue for anyone?
>>>
>>
>> Because libc++ is now in the monorepo, unless it needs a different
>> (patched?) version from llvm's main one, it should not need its own copy.
>>
>> AFAIK, the usual benchmark infrastructure compiles clang on demand and
>> then use that on the test-suite repo. However, that doesn't mean the repos
>> are on the same machine. For example, if you compile clang on a larger
>> cluster, install+pack and send to a more focued machine to do the
>> single-threaded-single-use-no-services benchmarking.
>>
>> So, I'd say it should be safe to merge libc++ and llvm one, but not
>> necessarily the test-suite one.
>>
>> If we don't have any local patches on those, we could also just clone it
>> from some known hash at runtime, or $deity forbid, as a submodule. :D
>>
>
> Putting it together, it seems like we can start with unifying the 2 in
> llvm/libcxx, then figure llvm-test-suite along the lines discussed so far.
>
> For the former, libcxx seems to have been updated most recently, I'll copy
> that one over to llvm/utils, seems benign, unless I'm missing something.
>
>
>
>>
> cheers,
>> --renato
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211025/ce60e6fb/attachment.html>


More information about the llvm-dev mailing list