<div dir="ltr">Circling back from <a href="https://reviews.llvm.org/D112012#3078815" rel="noreferrer" target="_blank">https://reviews.llvm.org/D112012</a> - 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`)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 10:28 PM Mircea Trofin <<a href="mailto:mtrofin@google.com">mtrofin@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 6:45 AM Renato Golin <<a href="mailto:rengolin@gmail.com" target="_blank">rengolin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, 12 Oct 2021 at 21:20, Mircea Trofin <<a href="mailto:mtrofin@google.com" target="_blank">mtrofin@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>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? </div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>So, I'd say it should be safe to merge libc++ and llvm one, but not necessarily the test-suite one.</div><div><br></div><div>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</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>cheers,</div><div>--renato</div></div></div>
</blockquote></div></div>
</blockquote></div>