[llvm] [SPIR-V][Codegen] Represent the property of the target to declare and use typed pointers and update MachineVerifier to use it (PR #110270)

[Vyacheslav Levytskyy via llvm-commits]

VyacheslavLevytskyy wrote:

> If you need an opcode to represent a point in the code where the operand needs to be inferred to a different pointer type than result, please add a new target-specific opcode for that, instead of trying to reuse G_BITCAST.

I can't say that I agree with (or maybe understand the reason for) the implemented machine verification of G_BITCAST arguments, because it voluntarily restricts `bitcast` definition in LLVM IR (https://llvm.org/docs/LangRef.html#i-bitcast): "If the source type is a pointer, the destination type must also be a pointer of the same size", and changes its behavior wrt. address spaces: "Pointer ... types may only be converted to other pointer ... types with the same address space ...".

But almost certainly I just miss some important aspects of this, that's why I need the feedback from experienced contributors. Let me please recap, to be 100% sure that I correctly understood your advice. Are the shift in G_BITCAST's semantics and maintenance burden, that this PR suggests, substantial to the degree when it's better to explicitly convert original `bitcast` to a call site and lower this call directly to SPIRV's `OpBitcast`, ignoring existing GISel's support for `bitcast`?

===

In a wider context, this probably a question of whether developers of SPIRV should try to (non-invasively) enrich GISel with the notion of a target that differs from traditional cpu/gpu targets, or rather reasons of maintenance, etc. make this solely a problem of the SPIRV target's code base and GISel should remain intact with this respect?

https://github.com/llvm/llvm-project/pull/110270