rephrase SPIR-V "Data Format for Reading and Writing Images"

[bashbaug]

from a SYCL discussion: intel/llvm#21366 (comment)

I think we should consider rephrasing the requirements in the OpenCL SPIR-V environment spec in the Data Format for Reading and Writing Images section to enable additional static SPIR-V validation.

Specifically, I think we should tie vector vs. scalar data to the Depth operand in the OpTypeImage, which is testable and known at compile time, instead of the Image Channel Order, which is only known at runtime. Strictly speaking, this is tightening some requirements, but I believe all SPIR-V generators are adhering to these requirements in practice, and all SPIR-V consumers are assuming these requirements are present.

The changes I propose are:

1. Add two requirements to Section 2.5.2 - Image-Related Data Types:
   • Behavior is undefined if an OpTypeImage with Depth = 0 has a Depth or DepthStencil image channel order.
   • Behavior is undefined if an OpTypeImage with Depth = 1 does NOT have a Depth or DepthStencil image channel order.
   • We can figure out the exact way to phrase these requirements, but informally, this means that a compiler and the validator can look at the Depth operand to determine whether or not the image is a depth image.
2. Given (1), we can therefore:
   • Update Table 11 Mapping Image Data to Vector Components to say that the data must be a four-component vector type when Depth = 0.
   • Update Table 12 Scalar Image Data to say that the data must be a scalar type when Depth = 1.
   • These requirements can be tested in the SPIR-V validator.

Note that we aren't able to statically test whether the data should be floating-point or integer (Table 13 Image Data Types), since the image channel order is still known only at runtime, but testing for scalar data vs. vector data is much better than nothing.