The backend infrastructure has a notion of input sources, of which there are two at the moment: LiftUnknown, which is basically unused, and LiftLitmus, which is currently generally hard-coded everywhere. There is actually a distinction between C litmus tests and assembly litmus tests: while Herd and Litmus both accept both, rmem only accepts assembly tests, and generally we don't want to use the other two in assembly litmus mode in most cases.
Ideally, we want three things here:
a split between LiftCLitmus and LiftAsmLitmus (where lift jobs targeting the latter pick up the architecture from the existing field on the job);
a way of checking the architecture of a Litmus test, which might be useful for auto-inferring the type (combined with filekind.GuessFromFile, I guess);
The backend infrastructure has a notion of input sources, of which there are two at the moment:
LiftUnknown
, which is basically unused, andLiftLitmus
, which is currently generally hard-coded everywhere. There is actually a distinction between C litmus tests and assembly litmus tests: while Herd and Litmus both accept both, rmem only accepts assembly tests, and generally we don't want to use the other two in assembly litmus mode in most cases.Ideally, we want three things here:
LiftCLitmus
andLiftAsmLitmus
(where lift jobs targeting the latter pick up the architecture from the existing field on the job);filekind.GuessFromFile
, I guess);LiftLitmus
in places.