Still a work-in-progress and I can most likely reuse more code, but at least I adapted the code to use some of the SPIRV-Tools interface/code.

Missing:

• [x] Update SPIR-V version support from 1.0 to 1.2
• [X] Remove duplicate types
• [x] Remove duplicate decorations
• [ ] Remove duplicate names
• [X] Remove duplicate categories
• [x] Remove duplicate SpvOpExtInstImport
• [x] Tests
• [x] Ensure that an import/export pair of variables or functions have the same interface before accepting to link

Questions:

• Should the linker require the given binaries to be valid SPIR-V binaries?
• Should the linker require the given binaries to have the same endianness as the host?

Fixes https://github.com/KhronosGroup/SPIRV-Tools/issues/937

The following checks are performed for structs that are decorated as Block or BufferBlock:

• No GLSLShared or GLSLPacked decoration should be used by any members.
• All members need to have Offset decoration. Arrays should have ArrayStride and matrices MatrixStride decorations.
• Blocks need to follow std140 rules.
• BufferBlocks need to follow std430 rules.

This change adds a new CFG cleanup pass to spirv-opt. The intent of the pass is to act as a repository of a variety of common CFG cleanup actions (straightening, removal of unreachable code, etc).

It's my first change to SPIRV-Tools, so I'm sure it's full of inconsistencies and missing bits. One of the things I've been thinking is that it may make sense to coalesce other existing CFG cleanup passes into this one in the hopes of reducing the number of CFG/IR traversals needed during cleanup.

Or, perhaps, it's preferable to keep these passes separate. I understand that compile time is not an issue now, but I'm not sure if this might be challenging in the future (in my experience, this tends to be true at some point).

The code works and passes the trivial test I've added. I need to add more, but I want a first review pass so I can learn preferred idioms and ways of structuring the code.

Thanks.

This pass essentially eliminates "if" control flow when the "then" and "else" parts are empty.

Mark structured conditional branches live only if one or more instructions in their associated construct is marked live. After closure, replace dead structured conditional branches with a branch to its merge and remove dead blocks.

Besides eliminating a not-insignificant amount of dead code (up to %30) from real shaders, this optimization is most necessary for legalization as there are real life codes that are expecting the frontend/optimizer/spirv-generator to eliminate references to objects that are referenced statically but not dynamically under compile-time-constant conditions.

This code does its own dead block elimination, but will ultimately be replaced with a call the newly integrated cfg cleanup code.

My understanding is that there is a pass that does SROA (scalar_replacement_pass), so I'm somewhat surprised that in the attached shader it doesn't remove the struct

Here's a snippet from the shader:

    %152 = OpCompositeInsert %_struct_9 %123 %175 0
    %154 = OpCompositeInsert %_struct_9 %float_0 %152 0 2
    // snip
    %166 = OpCompositeExtract %v4float %154 0
    %168 = OpCompositeExtract %float %166 1
     %94 = OpFNegate %float %168
    %170 = OpCompositeInsert %v4float %94 %166 1
           OpStore %gl_Position %170

The shader has been compiled from HLSL via glslang, so the fact that the original shader has a struct makes sense - this is the struct for the vertex shader output - but it's odd that it's still there after all the optimizations.

sky.spv.zip

This is another in a series of passes designed to reduce SPIR-V file size.

For each entry point function, this pass will look for BranchConditionals with constant condition and convert to a branch. Any resulting dead blocks are eliminated. For all phi functions in merge block, replace all uses with the id corresponding to the living predecessor.

This pass requires that all control flow be structured to allow optimization.

This pass is most effective when preceeded by passes which eliminate local loads and stores, effectively propagating constant values into BranchConditionals where possible.

Note that is pass contains functions and data from previous passes in this series. These will be coalesced under the planned optimization context class.

I have opened an issue about this in glslang, before figuring out it's actually due to a recent change in SPIRV-Tools https://github.com/KhronosGroup/glslang/issues/2148

Let me copy the initial issue here under The only additional information I've uncovered since, is that this is indeed due to a quite recent change in how the merge return pass is implemented: https://github.com/KhronosGroup/SPIRV-Tools/commit/e7afeb060e1637ca964c62517c3e6c225704b7eb which was undertaken under this issue https://github.com/KhronosGroup/SPIRV-Tools/issues/3127

It seems glslang has come up with (or increased the frequency of), sometimes in the previous months, I think, a rather peculiar pattern which looks something like this (in pseudo-code since the output is actually SPIR-V):

    vec4 _801;
    switch (0u)
    {
        default:
        {
            if (/* ... */)
            {
                _801 = /* assign a value */;
                break;
            }
            _801 = /* assign another value */;
            break;
        }
    }

This seems to happen in the HLSL to SPIR-V path at least, when inlining a function that conditionally returns different possible values, although I couldn't reduce my sample far enough to isolate exactly when that happens. Is there a good specific reason for this peculiar idiom ?

Albeit not incorrect, this kind of code is problematic in the case of D3D related pipelines. When fed to the D3D shader compiler, such code, having gone through glslang at some point, turns out to be highly problematic, as the D3D compiler is both incapable to correctly analyse that no code paths ends up with the variable potentially uninitialized — in the case of those tricky switch statements, and at the same time very picky about reading from unitialized variables, producing hard compile errors in those cases.

I'm not opening this issue to unequivocally say: it's something glslang should fix, but if you have any insights about how this was introduced and potential ways to workaround this problem. The responsibility of fixing this could be pushed to the next cross compiler in the chain, but it seems a rather complex task, so I'm pessimistic about the feasability. Fixing the D3D compiler itself doesn't seem easily doable either. Finally, would it be conceivable to make this behavior somehow togglable trough some sort of option ?

Many of my shaders that were previously passing spirv-val (last tested at Vulkan SDK 1.1.121.0) now fail with Vulkan SDK 1.2.131.2. The specific error is:

c:\vulkansdk\1.2.131.2\Bin\spirv-val shader_0085.spv error: line 956: Header block 12163[%12163] is contained in the loop construct headed by 6548[%6548], but its merge block 17470[%17470] is not %12163 = OpLabel

An example spir-v file is attached. I was talking to @greg-lunarg about this. The question is whether this is legitimately a bad shader or a spirv-val bug, and then second where in the spirv-opt chain this might get introduced.

Filing here first to triage the issue, also in case someone else already has hunted this down and knows offhand what the problem is.

shader_0085.zip

I have run into a problem with spirv-opt since the release of Vulkan SDK 1.0.68.0. The remove-duplicates pass seems to be clobbering my shader. Prior to that release, things were fine. This may well be something that I am doing wrong, but I have been unable to determine what thus far.

spirv-opt from Vulkan SDK 1.0.68.0 self-identifies as:

SPIRV-Tools v2018.1-dev v2018.0-6-g9e19fc0

The original SPIR-V is constructed by glslangValidator from the same SDK.

Some relevant bits from my shader:

layout(set = 0, binding = 5, std140) uniform atmosphere_fragment_uniforms {
	float sun_radius;
};

layout(set = 1, binding = 12, std140) uniform planet_dynamic_uniforms {
	float lod_factor;
};

Before any optimisation the disassembly shows the following section:

OpName %planet_dynamic_uniforms "planet_dynamic_uniforms"
OpMemberName %planet_dynamic_uniforms 0 "lod_factor"

After running just the remove-duplicates pass this has changed to:

OpName %atmosphere_fragment_uniforms "planet_dynamic_uniforms"
OpMemberName %atmosphere_fragment_uniforms 0 "lod_factor"

There are other changes, but off the bat this seems odd.

Running the optimiser with every -O pass except for remove-duplicates generates SPIR-V that appears to work fine.

I tried using spirv-opt from the CI build from commit 6cd6e5ebef0623a863ca2d8152edda75dd5001df, but with no change in behaviour.

The following is a cut-down that generates the odd difference when running just remove-duplicates:

#version 450 core

layout(set = 1, binding = 12, std140) uniform planet_dynamic_uniforms {
	float lod_factor;
};

layout(set = 0, binding = 5, std140) uniform atmosphere_fragment_uniforms {
	float sun_radius;
};

layout(location = 0) out vec4 out_colour;

void main() {
	out_colour = vec4(1.0);
}

To demonstrate the difference:

glslangValidator -V -o cutdown.spv cutdown.frag
spirv-opt -o cutdown.opt.spv --remove-duplicates cutdown.spv
spirv-dis -o cutdown.s cutdown.spv
spirv-dis -o cutdown.opt.s cutdown.opt.spv
fc /l cutdown.s cutdown.opt.s

The attached zip file contains three SPIR-V fragment shaders that demonstrate spirv-opt producing invalid SPIR-V. Unfortunately, the SPIR-V does not fail spirv-val, but it has crashed on two different drivers. Kerch Holt looked at the SPIR-V and determined there was a problem. Specifically:

The following snippet of SPIRV seems incorrect. It doesn’t seem like it is “structured control flow”. The OpSelectionMerge is pointing to %7205 yet there are jumps outside of this region. Seems like this code is something like : cond ? goto X : goto Y; That isn’t allowed in structured flow: 1987 OpSelectionMerge %7205 None 1988 OpBranchConditional %22516 %21999 %7205 1989 %21999 = OpLabel 1990 OpBranch %24266 1991 %7205 = OpLabel 1992 OpBranch %7840 1993 %7840 = OpLabel 1994 %11181 = OpPhi %float %11180 %21998 %20516 %7205 1995 %14351 = OpPhi %v3float %14347 %21998 %7885 %7205 1996 %12949 = OpPhi %mat3v4float %15174 %21998 %14541 %7205 1997 %16228 = OpPhi %_struct_1268 %15060 %21998 %7120 %7205 1998 %17815 = OpFAdd %float %15154 %float_1 1999 OpBranch %20259 2000 %24266 = OpLabel"

The shaders attached to the bug are:

• generic_vfx_ps_1.spv - this is the SPIR-V that comes out of the HLSL front-end of glslang
• generic.vfx_ps_1.spvopt.spv - this is after running spirv-opt with the following options: spirv-opt.exe --inline-entry-points-exhaustive --convert-local-access-chains --eliminate-local-single-block --eliminate-local-single-store --eliminate-insert-extract --eliminate-dead-code-aggressive --eliminate-dead-branches --merge-blocks --eliminate-local-single-block --eliminate-local-single-store --eliminate-local-multi-store --eliminate-insert-extract --eliminate-dead-code-aggressive
• generic.vfx_ps_1.spvopt_spvremapper.spv - this is the shader we actually send to the driver which runs spirv-remapper

Both of the last two shaders are crashing drivers, so spirv-opt alone is enough to cause the crash. I included the last one because it has the code that Kerch identified as being incorrect so hopefully makes it easier to identify the issue.

spirv_opt_bug.zip

A secondary issue here is once there is agreement this is invalid spirv, spirv-val should probably get an issue to detect this case since it currently does not.

Specifics Windows 7, Nvidia GTX 660 Ti, Driver 368.39

Have Vulkan SDK 1.0.21 installed for validation layers and set environment variable VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation

To reproduce I run all of the dEQP-VK.glsl.functions.control_flow.* tests from the Vulkan Conformance Test Suite

Message: Exception thrown: read access violation. this was nullptr. (debugger confirms that variable "this" is NULL)

Location: BasicBlock.h:

76 /// Returns true if the block is reachable in the CFG
77 bool reachable() const { return reachable_; }

Call Stack:

    VkLayer_core_validation.dll!libspirv::BasicBlock::reachable() Line 77   C++

    VkLayer_core_validation.dll!libspirv::StructuredControlFlowChecks(const libspirv::ValidationState_t & _, const libspirv::Function & function, const std::vector<std::pair<unsigned int,unsigned int>,std::allocator<std::pair<unsigned int,unsigned int> > > & back_edges) Line 349 C++

    VkLayer_core_validation.dll!libspirv::PerformCfgChecks(libspirv::ValidationState_t & _) Line 478    C++

    VkLayer_core_validation.dll!spvValidate(const spv_context_t * const context, spv_const_binary_t * const binary, spv_diagnostic_t * * pDiagnostic) Line 209  C++

    VkLayer_core_validation.dll!core_validation::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 9069  C++

    VkLayer_object_tracker.dll!object_tracker::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 3583    C++

    VkLayer_parameter_validation.dll!parameter_validation::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 2621    C++

    VkLayer_threading.dll!threading::CreateShaderModule(VkDevice_T * device, const VkShaderModuleCreateInfo * pCreateInfo, const VkAllocationCallbacks * pAllocator, VkShaderModule_T * * pShaderModule) Line 1133  C++

    deqp-vk.exe!vk::DeviceDriver::createShaderModule(vk::VkDevice_s * device, const vk::VkShaderModuleCreateInfo * pCreateInfo, const vk::VkAllocationCallbacks * pAllocator, vk::Handle<14> * pShaderModule) Line 218  C++

    deqp-vk.exe!vk::createShaderModule(const vk::DeviceInterface & vk, vk::VkDevice_s * device, const vk::VkShaderModuleCreateInfo * pCreateInfo, const vk::VkAllocationCallbacks * pAllocator) Line 209    C++

    deqp-vk.exe!vk::createShaderModule(const vk::DeviceInterface & deviceInterface, vk::VkDevice_s * device, const vk::ProgramBinary & binary, unsigned int flags) Line 206 C++
    deqp-vk.exe!vkt::`anonymous namespace'::PipelineProgram::PipelineProgram(vkt::Context & context, const glu::sl::ShaderCaseSpecification & spec) Line 745    C++

    deqp-vk.exe!vkt::`anonymous namespace'::ShaderCaseInstance::ShaderCaseInstance(vkt::Context & context, const glu::sl::ShaderCaseSpecification & spec) Line 1410 C++

    deqp-vk.exe!vkt::`anonymous namespace'::ShaderCase::createInstance(vkt::Context & context) Line 1791    C++

    deqp-vk.exe!vkt::TestCaseExecutor::init(tcu::TestCase * testCase, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & casePath) Line 246   C++

    deqp-vk.exe!tcu::TestSessionExecutor::enterTestCase(tcu::TestCase * testCase, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & casePath) Line 181   C++

    deqp-vk.exe!tcu::TestSessionExecutor::iterate() Line 101    C++

    deqp-vk.exe!tcu::App::iterate() Line 172    C++

    deqp-vk.exe!main(int argc, const char * * argv) Line 55 C++
    [External Code] 

Bisected to spirv-tools commit: f61db0bcc6717b4b60a7e38e7c3c58ad02110aa8 Validator structured flow checks: back-edge, constructs

Originally posted by @Tony-LunarG in https://github.com/google/shaderc/issues/234:

Given the following GLSL:

#version 310 es

precision highp float;

layout(location = 10) in highp vec4 vertex_uv01;
layout(binding = 0, set = 3) uniform sampler2D materialParams_baseColorMap;

layout(location = 0) out vec4 fragColor;

void main() {
  fragColor = texture(materialParams_baseColorMap, vertex_uv01.xy);
}

After compiling with glslangValidator, optimizing for performance, and running a --convert-relaxed-to-half pass, the texture sample gets translated to the following SPIR-V:

%18 = OpLoad %v4float %vertex_uv01
%23 = OpFConvert %v4half %18
%19 = OpVectorShuffle %v2half %23 %23 0 1
%20 = OpImageSampleImplicitLod %v4float %14 %19

Cross-compiling results in the following MSL:

out.fragColor = materialParams_baseColorMap.sample(materialParams_baseColorMapSmplr, float2(half4(in.vertex_uv01).xy));

The half4 conversion seems unnecessary, and destroys the precision of vertex_uv01. A workaround is to mark materialParams_baseColorMap as highp, but if I understand correctly, the precision of a sampler shouldn't affect the UV coordinates' precision.

Here are the exact steps I'm using to reproduce: reproduce.zip

$ glslangValidator --version
Glslang Version: 11:11.13.0
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 11.13.0
GLSL Version: 4.60 glslang Khronos. 11.13.0
SPIR-V Version 0x00010600, Revision 1
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 11
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

$ spirv-cross
Git commit: a89dea3c Timestamp: 2022-12-21T11:05:50

$ spirv-opt --version
SPIRV-Tools v2022.5-dev v2022.4-46-g01a3b9be

SPIRV-Tools already uses Kokoro to run CI but it requires a member of the organization to manually add tags to the PR to start the CI process. This is somewhat cumbersome if you have contributors from multiple timezones.

To fix that I'm adding Github Actions to Build/Test this repository using the Bazel builds. The build is relatively slow (~30m) due to the small amount of resources on the freely hosted Github runners. We use caches to bring no-op Linux/Mac builds to ~2m. The Windows ones are unfortunately not working right now but it does not break the build.

Crash stack trace:

operator delete(void * block) Line 38
operator delete(void * block, unsigned __int64 __formal) Line 32
std::_Deallocate<16,0>(void * _Ptr, unsigned __int64 _Bytes) Line 255
std::allocator<spvtools::opt::Operand>::deallocate(spvtools::opt::Operand * const _Ptr, const unsigned __int64 _Count) Line 798
std::vector<spvtools::opt::Operand,std::allocator<spvtools::opt::Operand>>::_Tidy() Line 1754
std::vector<spvtools::opt::Operand,std::allocator<spvtools::opt::Operand>>::~vector<spvtools::opt::Operand,std::allocator<spvtools::opt::Operand>>() Line 701
spvtools::opt::Instruction::~Instruction() Line 227
...
spvtools::opt::RedundancyEliminationPass::Process() Line 45
spvtools::opt::Pass::Run(spvtools::opt::IRContext * ctx) Line 37
spvtools::opt::PassManager::Run(spvtools::opt::IRContext * context) Line 58
spvtools::Optimizer::Run(const unsigned int * original_binary, const unsigned __int64 original_binary_size, std::vector<unsigned int,std::allocator<unsigned int>> * optimized_binary, spv_optimizer_options_t * const opt_options) Line 606

Test case 'dEQP-VK.pipeline.fast_linked_library.misc.interpolate_at_sample_no_sample_shading'.. PRE-OPT: ; SPIR-V

; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 11
; Bound: 56
; Schema: 0
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Vertex %4 "main" %35 %39 %51
OpMemberDecorate %33 0 BuiltIn Position
OpMemberDecorate %33 1 BuiltIn PointSize
OpMemberDecorate %33 2 BuiltIn ClipDistance
OpMemberDecorate %33 3 BuiltIn CullDistance
OpDecorate %33 Block
OpDecorate %39 BuiltIn VertexIndex
OpDecorate %51 Location 0
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeFloat 32
%7 = OpTypeVector %6 2
%8 = OpTypeInt 32 0
%9 = OpConstant %8 6
%10 = OpTypeArray %7 %9
%11 = OpTypePointer Private %10
%12 = OpVariable %11 Private
%13 = OpConstant %6 1
%14 = OpConstantComposite %7 %13 %13
%15 = OpConstant %6 -1
%16 = OpConstantComposite %7 %15 %13
%17 = OpConstantComposite %7 %15 %15
%18 = OpConstantComposite %7 %13 %15
%19 = OpConstantComposite %10 %14 %16 %17 %17 %18 %14
%20 = OpTypeArray %6 %9
%21 = OpTypePointer Private %20
%22 = OpVariable %21 Private
%23 = OpConstant %6 0.100000001
%24 = OpConstant %6 0.200000003
%25 = OpConstant %6 0.300000012
%26 = OpConstant %6 0.400000006
%27 = OpConstant %6 0.5
%28 = OpConstant %6 0.600000024
%29 = OpConstantComposite %20 %23 %24 %25 %26 %27 %28
%30 = OpTypeVector %6 4
%31 = OpConstant %8 1
%32 = OpTypeArray %6 %31
%33 = OpTypeStruct %30 %6 %32 %32
%34 = OpTypePointer Output %33
%35 = OpVariable %34 Output
%36 = OpTypeInt 32 1
%37 = OpConstant %36 0
%38 = OpTypePointer Input %36
%39 = OpVariable %38 Input
%41 = OpTypePointer Private %7
%44 = OpConstant %6 0
%48 = OpTypePointer Output %30
%50 = OpTypePointer Output %6
%51 = OpVariable %50 Output
%53 = OpTypePointer Private %6
%4 = OpFunction %2 None %3
%5 = OpLabel
OpStore %12 %19
OpStore %22 %29
%40 = OpLoad %36 %39
%42 = OpAccessChain %41 %12 %40
%43 = OpLoad %7 %42
%45 = OpCompositeExtract %6 %43 0
%46 = OpCompositeExtract %6 %43 1
%47 = OpCompositeConstruct %30 %45 %46 %44 %13
%49 = OpAccessChain %48 %35 %37
OpStore %49 %47
%52 = OpLoad %36 %39
%54 = OpAccessChain %53 %22 %52
%55 = OpLoad %6 %54
OpStore %51 %55
OpReturn
OpFunctionEnd

POST-OPT: ; SPIR-V

; Version: 1.0
; Generator: Khronos Glslang Reference Front End; 11
; Bound: 60
; Schema: 0
OpCapability Shader
%1 = OpExtInstImport "GLSL.std.450"
OpMemoryModel Logical GLSL450
OpEntryPoint Vertex %4 "main" %35 %39 %51
OpMemberDecorate %33 0 BuiltIn Position
OpMemberDecorate %33 1 BuiltIn PointSize
OpMemberDecorate %33 2 BuiltIn ClipDistance
OpMemberDecorate %33 3 BuiltIn CullDistance
OpDecorate %33 Block
OpDecorate %39 BuiltIn VertexIndex
OpDecorate %51 Location 0
%2 = OpTypeVoid
%3 = OpTypeFunction %2
%6 = OpTypeFloat 32
%7 = OpTypeVector %6 2
%8 = OpTypeInt 32 0
%9 = OpConstant %8 6
%10 = OpTypeArray %7 %9
%13 = OpConstant %6 1
%14 = OpConstantComposite %7 %13 %13
%15 = OpConstant %6 -1
%16 = OpConstantComposite %7 %15 %13
%17 = OpConstantComposite %7 %15 %15
%18 = OpConstantComposite %7 %13 %15
%19 = OpConstantComposite %10 %14 %16 %17 %17 %18 %14
%20 = OpTypeArray %6 %9
%23 = OpConstant %6 0.100000001
%24 = OpConstant %6 0.200000003
%25 = OpConstant %6 0.300000012
%26 = OpConstant %6 0.400000006
%27 = OpConstant %6 0.5
%28 = OpConstant %6 0.600000024
%29 = OpConstantComposite %20 %23 %24 %25 %26 %27 %28
%30 = OpTypeVector %6 4
%31 = OpConstant %8 1
%32 = OpTypeArray %6 %31
%33 = OpTypeStruct %30 %6 %32 %32
%34 = OpTypePointer Output %33
%35 = OpVariable %34 Output
%36 = OpTypeInt 32 1
%37 = OpConstant %36 0
%38 = OpTypePointer Input %36
%39 = OpVariable %38 Input
%44 = OpConstant %6 0
%48 = OpTypePointer Output %30
%50 = OpTypePointer Output %6
%51 = OpVariable %50 Output
%56 = OpTypePointer Function %10
%57 = OpTypePointer Function %7
%58 = OpTypePointer Function %20
%59 = OpTypePointer Function %6
%4 = OpFunction %2 None %3
%5 = OpLabel
%22 = OpVariable %58 Function
%12 = OpVariable %56 Function
OpStore %12 %19
OpStore %22 %29
%40 = OpLoad %36 %39
%42 = OpAccessChain %57 %12 %40
%43 = OpLoad %7 %42
%45 = OpCompositeExtract %6 %43 0
%46 = OpCompositeExtract %6 %43 1
%47 = OpCompositeConstruct %30 %45 %46 %44 %13
%49 = OpAccessChain %48 %35 %37
OpStore %49 %47
%54 = OpAccessChain %59 %22 %40
%55 = OpLoad %6 %54
OpStore %51 %55
OpReturn
OpFunctionEnd

This PR implements a C interface for the Optimizer class. It follows the same pattern established by the existing C interfaces for other classes in SPIRV-Tools.