A lot of the act-tester framework is actually fairly portable to things that don't fit our toolflow, such as CSmith. Being able to run CSmith (or yarpgen, etc) experiments 'as if' they are act-fuzz experiments would be useful for comparing the approach empirically, improve the tester's general usefulness, and let us use any UX, archival support, parallelisation etc. we build on the tester. Another advantage would be slightly better native support for generating CSmith coverage outputs.
I'm labelling this as a 'moonshot' because there are a few differences that would need a fair bit of generalising, and the workload is a bit too much to consider right now:
No input needed; ideally there would be a feedback where the planner wouldn't bother picking up inputs if its target fuzzer didn't need them.
Subjects would need to grow the ability to have non-Litmus files assigned to them.
Output is compilable C, and therefore doesn't need lifting; ideally act-tester would be able to assign different lifters to different input file types, and so it'd register litmus7 by default for litmus and a no-op for C.
Running recipe would be slightly different, eg no stats scraping.
A lot of the
act-testerframework is actually fairly portable to things that don't fit our toolflow, such as CSmith. Being able to run CSmith (or yarpgen, etc) experiments 'as if' they are act-fuzz experiments would be useful for comparing the approach empirically, improve the tester's general usefulness, and let us use any UX, archival support, parallelisation etc. we build on the tester. Another advantage would be slightly better native support for generating CSmith coverage outputs.I'm labelling this as a 'moonshot' because there are a few differences that would need a fair bit of generalising, and the workload is a bit too much to consider right now:
litmus7by default for litmus and a no-op for C.