[llvm] [X86][GlobalISel] Enable G_BUILD_VECTOR and G_CONSTANT_POOL (PR #92844)

[Evgenii Kudriashov via llvm-commits]

================
@@ -552,6 +579,73 @@ X86LegalizerInfo::X86LegalizerInfo(const X86Subtarget &STI,
   verify(*STI.getInstrInfo());
 }
 
+bool X86LegalizerInfo::legalizeCustom(LegalizerHelper &Helper, MachineInstr &MI,
+                                      LostDebugLocObserver &LocObserver) const {
+  MachineIRBuilder &MIRBuilder = Helper.MIRBuilder;
+  MachineRegisterInfo &MRI = *MIRBuilder.getMRI();
+  switch (MI.getOpcode()) {
+  default:
+    // No idea what to do.
+    return false;
+  case TargetOpcode::G_BUILD_VECTOR:
+    return legalizeBuildVector(MI, MRI, Helper);
+  }
+  llvm_unreachable("expected switch to return");
+}
+
+bool X86LegalizerInfo::legalizeBuildVector(MachineInstr &MI,
+                                           MachineRegisterInfo &MRI,
+                                           LegalizerHelper &Helper) const {
+  MachineIRBuilder &MIRBuilder = Helper.MIRBuilder;
+  const auto &BuildVector = cast<GBuildVector>(MI);
+  Register Dst = BuildVector.getReg(0);
+  LLT DstTy = MRI.getType(Dst);
+  if (!isConstantOrConstantVector(MI, MRI, /* AllowFP */ true)) {
----------------
e-kud wrote:

Yes, it makes sense. I have a local version when a non constant `G_BUILD_VECTOR` is legalized through a series of `G_INSERT_VECTOR_ELT`. But I haven't looked for scenarios when legalizer may create `G_BUILD_VECTOR` with non constant values as SelectionDAG does. So this check came from this version. Will address in PR with `G_INSERT_VECTOR_ELT` or even separately.

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