[SPIRV] Legalize long vectors in GlobalISel

[s-perron]

This commit introduces support for legalizing long vectors (vectors with more
than 4 elements) in the SPIR-V backend using GlobalISel. This is primarily
for shader compilation where the GLSL_std_450 instruction set is available.

The main changes include:

• Adding legalization rules for vector operations (G_BUILD_VECTOR,
  G_SHUFFLE_VECTOR, G_EXTRACT_VECTOR_ELT, G_BITCAST, G_CONCAT_VECTORS)
  to split vectors with more than 4 elements into smaller vectors.
• Enhancing the SPIRVPostLegalizer with a worklist-based approach to
  correctly process instructions and types generated during legalization.
• Lowering G_EXTRACT_VECTOR_ELT to a spv_extractelt intrinsic.
• Refining the handling of G_BITCAST to legalize non-pointer bitcasts.
• Marking many SPIR-V operations as pure to aid optimization.

[s-perron]

I'd like some feedback on the overall direction I'm going with this. No need for a detailed review yet. I will open smaller PRs (with tests) for parts of these changes. I'd like to know if people agree with some of the major design changes:

1. The post legalizer pass changes from a single pass transformation to a multipass one using a work list. The reason for this change is that we sometime need to look at the operands to determine the type of the new instructions, and we sometimes have to look at it uses. I could also try two pass: a forward pass an a backward pass. I was not able to convince myself that would work in all cases, but I didn't think about it carefully.
2. I want to change the pre-legalizer to not convert G_Bitcast to an intrinsic. It is much more work to legalize the intrinsic. Could we use G_Bitcast and G_Copy working together? I still have to implement that. Is there a reason that will not work?
3. I changed many ops to be flagged as not having side effects. This allows them to be removed during instruction selection if they are trivially dead.

I think those are the major design decision. Let me know if there is any other high level changes you might have concerns about.

[s-perron]

We could keep the bitcast intrinsic. I could add a custom rule in the legalizer to turn the intrinsic in a G_Bitcast if contains large vectors. Use the existing rules to legalize the G_Bitcast, and then turn a G_Bitcast back into the bitcast intrinsic after legalization. That might be the better way to do it. A G_Copy could get optimized away, and cause other problems.

[MrSidims]

I don't have immediate objections against the approach, but I do want to take a look at it in details by tomorrow.

[s-perron]

The first independent PR is #164868. This changes some opcode so they do not have side effects.

[s-perron]

I have smaller PRs open for this now. I'll close this one.