Add decorate operations new to SPIR-V 1.4

OpDecorateId was added to SPIR-V 1.2, but was missing from SwiftShader.
OpDecorateString and OpMemberDecorateString were added in SPIR-V 1.4 as
a part of the SPV_GOOGLE_decorate_string extension being integrated as
a core part of SPIR-V 1.4.

All of the decorations for these operations are to support HLSL at a
level before the graphics driver is involved, to include debug
information in the SPIR-V code, or to inform the SPIR-V compiler about
potential optimizations that SwiftShader currently doesn't implement.

Test: dEQP-VK.spirv_assembly.instruction.spirv1p4.hlsl_functionality1.*
Test: dEQP-VK.spirv_assembly.instruction.spirv1p4.uniformid.*
Bug: b/174693410
Change-Id: I7a22b335da9f5566e3d08869a80ea6701f035155
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/50850
Tested-by: Sean Risser <srisser@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
diff --git a/src/Pipeline/SpirvShader.cpp b/src/Pipeline/SpirvShader.cpp
index 0f66987..0c8ab83 100644
--- a/src/Pipeline/SpirvShader.cpp
+++ b/src/Pipeline/SpirvShader.cpp
@@ -139,6 +139,25 @@
 				break;
 			}
 
+			case spv::OpDecorateId:
+			{
+				auto decoration = static_cast<spv::Decoration>(insn.word(2));
+
+				// Currently OpDecorateId only supports UniformId, which provides information for
+				// potential optimizations that we don't perform, and CounterBuffer, which is used
+				// by HLSL to build the graphics pipeline with shader reflection. At the driver level,
+				// the CounterBuffer decoration does nothing, so we can safely ignore both decorations.
+				ASSERT(decoration == spv::DecorationUniformId || decoration == spv::DecorationCounterBuffer);
+				break;
+			}
+
+			case spv::OpDecorateString:
+			case spv::OpMemberDecorateString:
+			{
+				// We assume these are for HLSL semantics, ignore them.
+				break;
+			}
+
 			case spv::OpDecorationGroup:
 				// Nothing to do here. We don't need to record the definition of the group; we'll just have
 				// the bundle of decorations float around. If we were to ever walk the decorations directly,
@@ -1684,6 +1703,9 @@
 		case spv::OpGroupDecorate:
 		case spv::OpGroupMemberDecorate:
 		case spv::OpDecorationGroup:
+		case spv::OpDecorateId:
+		case spv::OpDecorateString:
+		case spv::OpMemberDecorateString:
 		case spv::OpName:
 		case spv::OpMemberName:
 		case spv::OpSource: