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

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

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211013/6cc4f442/attachment.html>

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/20211013/fd26d6f1/attachment.html>