llvm.experimental.constrained intrinsics generate invalid SPIR-V

[bashbaug]

Currently, at least some of the llvm.experimental.constrained intrinsics are generating invalid SPIR-V. Specifically, they are adding the FPRoundingMode decoration to instructions that do not support this decoration, for the OpenCL SPIR-V environment at least, see:

https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_rounding_modes_for_conversions

These validation failures are not currently flagged by spirv-val, but they may be shortly, see:

KhronosGroup/SPIRV-Tools#6537

What should we do in this case? Some options:

1. Fail translation - there is nothing in SPIR-V we can translate to.
2. Drop the unsupported rounding mode decorations, potentially with a warning diagnostic.
3. Do nothing and keep generating invalid SPIR-V, in which case a few tests will need to be updated to stop running spirv-val.

[MrSidims]

UPD: what I have missed is:

3.2.15. FP Rounding Mode
Associate a rounding mode to a floating-point conversion instruction.

so most of I wrote is irrelevant. Still I'm not sure what was meant in issue #2 in SPV_KHR_float_controls.

=======
irrelevant part:

I'm not sure that the validation error is right. The rule:
The FPRoundingMode [decoration](https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#Decoration) must be applied only to a width-only conversion instruction ....
is placed under Shader validation rules, hence it has no affect on Kernel translation.

for the OpenCL SPIR-V environment at least, see
https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Env.html#_rounding_modes_for_conversions

While this is true, but should the translator (and with the further extend SPIR-V backend) follow OpenCL environmental specification? Aka is Kernel SPIR-V just an alias to OpenCL-produced SPIR-V? I can imagine environments that could use Kernel SPIR-V for compute and not following OpenCL environment. For example level-zero has no such restriction (from what I see in https://oneapi-src.github.io/level-zero-spec/level-zero/latest/core/SPIRV.html , though it might be a spec bug :-) )

[MrSidims]

=======
irrelevant part:

So, should SPIR-V validator be checking rules set by environment specification(s)? AFAIK spirv-val has --target-env option. If it points to OpenCL (or Vulkan as Shader has validation rules in core spec) - sure, emit the error. Otherwise, if the module has Kernel capability, but nothing points to OpenCL is it a legit validation?

=======
relevant part:

Don't get me wrong, I'm not trying to promote some flavored SPIR-V, but just ability to have rounding mode decoration applied to arithmetic instructions seem to be useful. Also I have a feeling, that SPV_KHR_float_controls has an intention to allow as many as possible instructions be annotated with rounding mode, see:

Why not reuse FPRoundingMode?

RESOLVED: We would like to have an ability to specify the rounding mode on the global scope and also for a larger set of instructions than the FPRoundingMode decoration allows.

though it doesn't spell out this explicitly (and hence my feeling might be wrong). If my feeling is right, should the validator check if the extension is enabled?

[bashbaug]

Sorry for the slow reply, I missed this over the long weekend. These are all good observations.

Here are some specific things we could do:

1. Move the FPRoundingMode restriction out of the OpenCL SPIR-V environment spec and into the main SPIR-V spec, so it unambiguously applies to all Kernel SPIR-V.
   • Note that there is already a restriction documented in the SPIR-V spec for FPRoundingMode for Shader SPIR-V.
   • An extension could relax this restriction in the future, if desired, it'd just do so via a SPIR-V extension (since the restriction is in the SPIR-V specification) rather than in a client API extension.
   • This only makes sense if the restriction is currently the case for all Kernel SPIR-V consumers (which I believe is true?).
   • Maybe we should take "to a floating-point conversion instruction" out of the description of FPRoundingMode also?
2. Change the validator so it only applies these checks to the OpenCL environment. This is debatably the right thing to do, but it has two disadvantages: The OpenCL environments in spirv-val are a bit of a mess right now (but maybe this is a good excuse to clean it up), and we wouldn't be able to run as many checks by default.

I lean towards (1), if we can get away with it - and maybe we should consider moving some other Kernel restrictions into the SPIR-V spec while we're at it.

What do you think?

[MrSidims]

Thanks for the summary! I also lean towards (1).