If you do get a definitive answer from Apple you can share, please follow up here, as I would like to be able to cite it. I would be quite shocked if it's different than what I just said, though.
it's what is used for OpenCL on Metal (which is the impl present on M1) to provide the semantics there. AIR is a stable, forward compatible bytecode. Will ask and see what Apple says...
edit: thinking about this, OpenCL doesn't actually need those semantics either
Claiming OpenCL bitcode is "forward compatible" is a pretty strong claim considering that OpenCL has been deprecated for over 3 years, and the main thing you get when searching OpenCL docs on the Apple site is an exhortation to migrate to Metal. To the extent there's a forward compatibility guarantee for AIR, I'm sure it only applies to output generated by official Apple tools, and I'm pretty sure by now there's no way to get those to output a device-scope barrier.
Interestingly, the Apple driver seems to have that screwed up, with giving much stronger semantics than necessary...
#define _AIR_MEM_SCOPE_WORK_GROUP 0x2 in the OpenCL header
And for metal_types.h...
#define _AIR_MEM_SCOPE_WORK_GROUP 0x1
#define _AIR_MEM_SCOPE_DEVICE 0x2
Which made me have even more questions, that's why I couldn't give a straight answer earlier.
> OpenCL has been deprecated for over 3 years
The OpenCL implementation using AIR is new, for Apple Silicon.