Operands are treated as literals instead of ids at capability check

[AlexeySotkin]

In particular during validation of atomic instructions memory semantics operands are treated as literals, but according to the spec they must be id.

In the attached example, it happened that OpAtomicIAdd has memory semantics operand = %64. Literally it corresponds to 0x40 (UniformMemory, which require shader capability). But actually %64 is an id of an integer constant = 0x10(SequentiallyConsistent, no capability required).

%64 = OpConstant %2 16
...
%63 = OpAtomicIAdd %2 %50 %35 %64 %35

This causes false positive errors to be reported by spirv-val tool:

error: 129: Operand 5 of AtomicIAdd requires one of these capabilities: Shader

atomic_exchange.global_atomic_double_declared_in_program.used_in_generic_function.order_relaxed.spv20_32.zip

atomic_exchange.global_atomic_double_declared_in_program.used_in_generic_function.order_relaxed.spv20_32.txt

[dneto0]

Confirmed.

I tracked it down to the CapCheck function at https://github.com/KhronosGroup/SPIRV-Tools/blob/master/source/validate_instruction.cpp#L87

For operands that are IDs, it should not be checking the ID value itself, but rather the underlying constant if it can find one. Note that we should have a one-sided error, i.e. if we can't determine the value then let it pass. (This might occur if there's a complex expression the code doesn't know how to evaluate.

Looking at the operand types in libspirv.h, this kind of problem would only affect SPV_OPERAND_TYPE_MEMORY_SEMANTICS_ID (as in this reported but), or SPV_OEPRAND_TYPE_SCOPE_ID, but none of those values have required capabilities.

Sending to @umar456

[dneto0]

I have a stopgap PR that I'll post shortly.

[dneto0]

Workaround has been merged. I filed #252 for the "proper" (completist) fix.