[libcxx-commits] [PATCH] D143158: [libcxx][test] Cover RISC-V in string.capacity test

Wed Mar 8 02:59:47 PST 2023

asb added a comment.

In D143158#4159832 <https://reviews.llvm.org/D143158#4159832>, @ldionne wrote:

> In D143158#4144443 <https://reviews.llvm.org/D143158#4144443>, @asb wrote:
>
>> In D143158#4115961 <https://reviews.llvm.org/D143158#4115961>, @philnik wrote:
>>
>>> I'm not sure what exactly our requirements are on CI infrastructure, but I think for adding a new platform some compute resources have to be provided. I think the "existing infrastructure" note is mostly about general configurations, like a new C++ version, testing the unstable ABI and similar stuff. I'm not sure though. @ldionne should be able to give a definite answer here.
>>
>> Hi @ldionne - just a ping for your thoughts here (and on your thoughts about native RISC-V precommit being slow).
>>
>> I'd imagine the ideal case here for giving reasonable coverage without taking too long would be to cross-compile everything (all the compile-time tests would be covered here at least on the fast x86 host), and to run the tests that need executing using qemu-user-static. It looks like the linked Android test scripts are doing native x86_64 testing - is there an example in the current CI of a cross-build setup?
>>
>> There's also the question of what such tests would run on. If you have existing infra that's open to adding new jobs, it definitely seems easiest if that can be used - and it reduces the risk of unwanted failures due to bot-specific issues. But I can explore spinning up something myself if necessary.
>
> What hardware does https://lab.llvm.org/staging/#/builders/241 run on? I think we should use that hardware. If executing the tests is too slow, one thing we could do is only compile the tests without running them. This is definitely possible, we do that for some internal configurations, but it does require a bit of work on the Lit side. We do not have an example of how to do that upstream right now.
>
> For starters, what I would suggest is to set up a proper BuildKite bot that runs your RISC-V tests. Now that's going to be prohibitively slow, so I can suggest ways to make that faster and help you achieve the compile-only test suite on that Phab review once it's open. You can reach out to me privately on Discord to get a BuildKite agent token for your RISC-V runners.

It's running on a fast x86_64 host, using qemu-user within a RISC-V chroot/container. If we're going to be doing compile time tests anyway, wouldn't it make a lot more sense to do those compile-time tests using a cross compiler (i.e. running natively on a fast x86_64 host). If we do so, then it's just another configuration on the runners you already have.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143158/new/

https://reviews.llvm.org/D143158