Closed Bastacyclop closed 2 years ago
Porting the barrier tests from Lift makes sense to me.
Just for my understanding: Is point 2 captured by the tests? So in Lift the tests would pass because the code works? Do these tests pass for Rise? Would it make sense to check for invalid barriers rather than working code?
Are you going to keep track of these points as issue(s)?
Do these tests pass for Rise? Would it make sense to check for invalid barriers rather than working code?
The tests in Rise are not actually running the generated code (maybe they should), instead they count barriers as in:
"barrier".r.findAllIn(code).length shouldBe 2
"""barrier\(CLK_LOCAL_MEM_FENCE\)""".r.findAllIn(code).length shouldBe 2
It's not bullet proof as the right amount of barriers may appear in the wrong place, so the tests could be more sophisticated.
Are you going to keep track of these points as issue(s)?
This ports more than 40 barrier unit tests from the Lift repository to ours. Overall, Lift seems to generate less barriers, but also to generate more invalid barriers (see point 2.). The barrier insertion of Shine is more conservative and often looks more correct to me, but could be improved for performance (see point 1.).
mapSeq
/reduceSeq
which are outside of amapLocal
. I think such programs should be rejected and considered ill formed.