AlexVlx wrote: > An obvious problem with the quick path of appropriation of > DeviceOnlyINTEL/HostOnlyINTEL is that Storage Class stops having a semantic > meaning by itself, and we are able to interpret it only in the context of a > vendor. The standard extension mechanism guarantees that a SPIR-V module can > be interpreted in the context of its OpExtension instructions, denoting > extensions that added semantics referred by the module. Vendor info as a > source of truth is a shift from "SPIR-V module can be interpreted with the > specification and extension docs" premise.
This is true, with the caveat that flavoured SPIR-V being interpreted by anyone but the vendor / orthogonally to vendor specific considerations is problematic in and of itself. Yes, depending on what the user opted in into in terms of features, you can get a perfectly fine vanilla module. You can also get something that is impossible to interpret (even though it is technically valid SPIR-V, which we do try to retain). The challenge with pursuing the `OpExtension` here (which in the long run we would want to do anyways; in hindsight, a comment here would have been useful) is that these are rather hardware specific, still fluid, and tied to very target specific intrinsics. Encoding it early into an extension runs the risk of spawning what long term ends up as abandonware. Of course, and argument can always be made around "well just don't use it then", but that is contrary to the point of flavouring itself (it was meant to allow for spices beyond salt & vinegar). https://github.com/llvm/llvm-project/pull/199376 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
