Valid Operand Types for SPIR-V Printf Extended Instruction

[bashbaug]

The OpenCL SPIR-V environment spec should clarify which operand types are valid for the printf extended instruction, likely based on the printf format specifier for that operand.

For reference, the printf extended instruction currently says:

The printf extended instruction writes output to an implementation-defined stream such as stdout under control of the string pointed to by format that specifies how subsequent arguments are converted for output.

But neither it nor the OpenCL SPIR-V environment spec describe which operand types are valid.

Some example questions:

1. Is it valid for a printf operand to be an 8-bit integer or a 16-bit integer, or must smaller integers be up-converted to 32-bit integers?
2. If a device supports 16-bit floats (AKA fp16, AKA half) Is it valid for a printf operand to be a 16-bit float, or must smaller floats be up-converted to 32-bit or 64-bit floats?
3. If a device supports 64-bit floats (AKA fp64, AKA doubles), is it valid for a printf operand to be a 32-bit float, or must it be up-converted to a 64-bit float?
4. Are the rules for scalars the same as they are for vectors?

FWIW, the OpenCL C spec seems to say:

• Scalars integers smaller than 32-bits are promoted to 32-bit integers ("the argument will have been promoted according to the integer promotions").
• Vectors of integers are left as-is ("the argument will not be promoted"), even vectors of smaller than 32-bit integers.
• Scalar floats smaller than 64-bits are promoted to 64-bit floats if 64-bit floats are supported.
• Scalar floats smaller than 32-bits are promoted to 32-bit floats if 64-bit floats are not supported.
• Vectors of floats are left as-is.

This matches what Clang is doing: https://godbolt.org/z/Ebr5EqEsh

We could allow more than this via SPIR-V if we want to, or we could only allow what Clang is currently generating. What is the group's preference?

[bashbaug]

While we're at it, we also should document a few other OpenCL C requirements in the OpenCL SPIR-V environment spec, or decide that they have defined behavior via SPIR-V:

If a vector specifier appears without a length modifier, the behavior is undefined. The vector data type described by the vector specifier and length modifier must match the data type of the argument; otherwise the behavior is undefined.

If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined.

(related to: https://github.com/KhronosGroup/OpenCL-CTS/issues/2039)