Invalid SPIR-V generated for specialization constant based expression

[mplatings]

Description

glslang inconsistently lowers specialization-constant expressions involving && or ||.

When the right operand is itself a compound specialization-constant expression, the logical operation can be lowered to function control flow with an OpPhi. However, glslang continues treating the result as a specialization constant. A subsequent operation on that result is emitted as a module-scope OpSpecConstantOp referencing the function-local OpPhi, producing invalid SPIR-V.

To reproduce

With glslang 11:16.2.0:

$ cat reproducer.comp
#version 460

layout(constant_id = 0) const uint a = 0u;
const bool c = (a == 0u) && (a + 1u == 1u);

layout(local_size_x = 1) in;

void main() {
    if (!c)
        return;
}
$ glslang -V --target-env vulkan1.1 reproducer.comp -o reproducer.spv
reproducer.comp
$ spirv-val --target-env vulkan1.1 reproducer.spv
error: line 22: ID '16[%c]' has not been defined
  %17 = OpSpecConstantOp %bool LogicalNot %c

[arcady-lunarg]

Oh, this is a fun one, especially since the control flow that it generates is nonsense, it just does an OpBranchConditional between two empty blocks, with the OpPhi serving as, effectively, just an OpSelect. It normally generates control flow because of the short circuiting nature of && and || but this is neither necessary nor desirable when both sides are specialization constants and it should ideally be generating a OpSpecConstantOp LogicalAnd in this case.