This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Run headers_declare_verbose_abort.sh.cpp in parallel
AbandonedPublic

Authored by philnik on May 12 2023, 1:15 PM.

Details

Reviewers
None
Group Reviewers
Restricted Project

Diff Detail

Event Timeline

philnik created this revision.May 12 2023, 1:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 1:15 PM
philnik published this revision for review.May 15 2023, 11:15 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 15 2023, 11:15 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript

Please let's not do this. I mentioned that this was troublesome in https://reviews.llvm.org/D144640#inline-1408386. I really would appreciate to have that test fixed too.

I use lit to do determine how many jobs to start and now these tests start to spam extra jobs. I'm not against fixing this issue, but basically deciding for users that they can spawn 16 extra parallel jobs really sounds wrong to me. This has lead me a few times to an unresponsive system since I had other heavy tasks running in parallel.

Please let's not do this. I mentioned that this was troublesome in https://reviews.llvm.org/D144640#inline-1408386. I really would appreciate to have that test fixed too.

I use lit to do determine how many jobs to start and now these tests start to spam extra jobs. I'm not against fixing this issue, but basically deciding for users that they can spawn 16 extra parallel jobs really sounds wrong to me. This has lead me a few times to an unresponsive system since I had other heavy tasks running in parallel.

I don't plan to land this as-is. This was only to test how much the modules build can be improved, and I published it to remember to talk with Louis about this.

Please let's not do this. I mentioned that this was troublesome in https://reviews.llvm.org/D144640#inline-1408386. I really would appreciate to have that test fixed too.

I use lit to do determine how many jobs to start and now these tests start to spam extra jobs. I'm not against fixing this issue, but basically deciding for users that they can spawn 16 extra parallel jobs really sounds wrong to me. This has lead me a few times to an unresponsive system since I had other heavy tasks running in parallel.

I don't plan to land this as-is. This was only to test how much the modules build can be improved, and I published it to remember to talk with Louis about this.

Just recording what we discussed as a potential direction: have a Lit test format that allows generating arbitrary Lit tests (e.g. it generates JSON or Pickled Lit.Test objects) and adds it to the test suite. Maybe this needs to be hooked into getTestsInDirectory?

Please let's not do this. I mentioned that this was troublesome in https://reviews.llvm.org/D144640#inline-1408386. I really would appreciate to have that test fixed too.

I use lit to do determine how many jobs to start and now these tests start to spam extra jobs. I'm not against fixing this issue, but basically deciding for users that they can spawn 16 extra parallel jobs really sounds wrong to me. This has lead me a few times to an unresponsive system since I had other heavy tasks running in parallel.

I don't plan to land this as-is. This was only to test how much the modules build can be improved, and I published it to remember to talk with Louis about this.

Just recording what we discussed as a potential direction: have a Lit test format that allows generating arbitrary Lit tests (e.g. it generates JSON or Pickled Lit.Test objects) and adds it to the test suite. Maybe this needs to be hooked into getTestsInDirectory?

I really like that idea. Then the scheduling the tests is done by lit again and we can easily "split" these large tests.

philnik abandoned this revision.May 23 2023, 9:10 AM