Keep the value's pointer type when the emitted storage class is logical

[paoloantinori]

When -physical-storage-buffers is on, getSPIRVPointerOperand reconciles a pointer value's emitted SPIR-V type with the type its consumer expects by emitting an OpBitcast to the expected type. If the value was emitted with a logical storage class, that OpBitcast has a logical pointer operand, which is invalid SPIR-V:

error: Instruction may not have a logical pointer operand
  %14916 = OpBitcast %_ptr_PhysicalStorageBuffer_uint %14915
  %14915 = OpAccessChain %_ptr_Private_uint %55 %14913

This surfaces on the hashcat kernel from #1660 once both the parent branch's rehome (optimizer lookup tables become Private variables while some GEP users keep stale Global-AS types) and physical addressing are active: 32 occurrences, module rejected by spirv-val.

The fix records the storage class of every OpTypePointer the producer registers (a small type_id -> storage_class map filled at type creation) and uses it at the mismatch site: when the emitted class is logical, keep the value's own pointer (loads and stores through it stay in its storage class, which is legal); when both sides are PhysicalStorageBuffer, keep emitting the reconciling bitcast that issue #1637 and the fix in #1639 depend on. So this preserves the existing physical-to-physical path exactly.

Verification, on this branch (parent #1662 plus this delta):

• full preprocessed hashcat m22000 kernel, -arch=spir64 -physical-storage-buffers -O2: compiles and spirv-val --target-env vulkan1.2 is completely clean (previously the error above);
• the same kernel with the logical (default) addressing and clvk's full option set: unchanged, still clean;
• the existing test/PhysicalStorageBuffers/issue-1637.cl under the same physical options: still emits its physical-to-physical OpBitcast and validates clean;
• the included regression test compiles a kernel that exercises both the rehome (dense switch at -O2) and the mismatch site under physical addressing, FileChecks that the table lands as a Private variable with its initializer and that no OpBitcast %_ptr_PhysicalStorageBuffer from a logical operand is emitted, and validates at vulkan1.2.

Based on #1662 because the invalid bitcast only becomes reachable once the rehome exists; if #1662 lands first this applies cleanly on top.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[alan-baker]

Please rebase this change now that #1662 is merged.

[paoloantinori]

Rebased onto current main in dc34181. The branch now carries only the pointer-type fix and its regression test on top of the merged #1662. I verified on a local build of the rebased branch that the new test, the switch table test, and the issue-1637 test pass, and the full PointerCasts directory shows no new failures.

Separately, test/PointerCasts/issue-1187.ll fails on current main (975e3c8) for me with error: invalid LLVM IR input: domain must have one or two operands on the committed metadata. That looks like stale test data after an LLVM update rather than anything from these PRs.

[rjodinchr]

Because typed pointers are used here, spirv-dis prints %_ptr_PhysicalStorageBuffer_uint, so CHECK-NOT: OpBitcast %_ptr_PhysicalStorageBuffer %{{[0-9]+}} (with a space before %) won't actually match OpBitcast %_ptr_PhysicalStorageBuffer_uint %<id>.

Suggested change

	// CHECK-NOT: OpBitcast %_ptr_PhysicalStorageBuffer %{{[0-9]+}}
	// CHECK-NOT: OpBitcast

[paoloantinori]

Good catch, the check had no teeth. Applied in f708cab: the CHECK-NOT is now any OpBitcast. On this branch the disassembly contains zero OpBitcast at all, and the pre-fix output I captured from main yesterday (one OpBitcast with the typed pointer name) now fails the check as it should.