PtrAccessChain with a PhysicalStorageBuffer Base

[nanokatze]

Description of PtrAccessChain seems to say nothing about the case when the Base belongs to PhysicalStorageBuffer class.

To compute the new element address, Element is treated as a signed count of elements E, relative to the original Base element B, and the address of element B + E is computed using enough precision to avoid overflow and underflow. For objects in the Uniform, StorageBuffer, or PushConstant storage classes, the element’s address or location is calculated using a stride, which will be the Base-type’s Array Stride if the Base type is decorated with ArrayStride. For all other objects, the implementation calculates the element’s address or location.

I believe the intent was to use ArrayStride with PhysicalStorageBuffer Base as well? In practice spirv-val seems to be happy with PhysicalStorageBuffer Base that doesn't have ArrayStride decoration. Of drivers' compilers, NIR expects an explicit stride, blowing up on an assert otherwise, and Nvidia's seems to work as if stride was size of the pointee or 1 (the pointee size this was tested with was int8, so it's unknown whether it's the former or the latter.)

[jeffbolznv]

I think this was probably an oversight and OpPtrAccessChain should include PhysicalStorageBuffer in its list.

For NVIDIA's implementation, I believe we use the array stride if it's present, otherwise we fall back to the size of the element type.