[SPIRV] getOrCreateComposite and getOrCreate<Type> only support type that are 32bit wide

[farzonl]

There is a prexisting TODO on this, but no issue tracking it
so this issue will become the tracking.
Below is the stacktrace:

#0 0x000060969b04c53d llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /mnt/DevDrive/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:11
 #1 0x000060969b04ca2b PrintStackTraceSignalHandler(void*) /mnt/DevDrive/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:798:1
 #2 0x000060969b04aa96 llvm::sys::RunSignalHandlers() /mnt/DevDrive/projects/llvm-project/llvm/lib/Support/Signals.cpp:105:5
 #3 0x000060969b04d1e5 SignalHandler(int) /mnt/DevDrive/projects/llvm-project/llvm/lib/Support/Unix/Signals.inc:413:1
 #4 0x0000701f3f442520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #5 0x0000701f3f4969fc pthread_kill (/lib/x86_64-linux-gnu/libc.so.6+0x969fc)
 #6 0x0000701f3f442476 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x42476)
 #7 0x0000701f3f4287f3 abort (/lib/x86_64-linux-gnu/libc.so.6+0x287f3)
 #8 0x000060969af643f4 llvm::report_fatal_error(llvm::Twine const&, bool) /mnt/DevDrive/projects/llvm-project/llvm/lib/Support/ErrorHandling.cpp:125:5
 #9 0x000060969bd32def reportGISelDiagnostic(llvm::DiagnosticSeverity, llvm::MachineFunction&, llvm::TargetPassConfig const&, llvm::MachineOptimizationRemarkEmitter&, llvm::MachineOptimizationRemarkMissed&) /mnt/DevDrive/projects/llvm-project/llvm/lib/CodeGen/GlobalISel/Utils.cpp:264:5
#10 0x000060969bd32e55 llvm::reportGISelFailure(llvm::MachineFunction&, llvm::TargetPassConfig const&, llvm::MachineOptimizationRemarkEmitter&, llvm::MachineOptimizationRemarkMissed&) /mnt/DevDrive/projects/llvm-project/llvm/lib/CodeGen/GlobalISel/Utils.cpp:278:1
#11 0x000060969bd3302f llvm::reportGISelFailure(llvm::MachineFunction&, llvm::TargetPassConfig const&, llvm::MachineOptimizationRemarkEmitter&, char const*, llvm::StringRef, llvm::MachineInstr const&) /mnt/DevDrive/projects/llvm-project/llvm/lib/CodeGen/GlobalISel/Utils.cpp:291:1
#12 0x000060969bc95634 llvm::InstructionSelect::runOnMachineFunction(llvm::MachineFunction&) /mnt/DevDrive/projects/llvm-project/llvm/lib/CodeGen/GlobalISel/InstructionSelect.cpp:289:7
#13 0x0000609699a897f6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /mnt/DevDrive/projects/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:93:8
#14 0x000060969a1ebb4a llvm::FPPassManager::runOnFunction(llvm::Function&) /mnt/DevDrive/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1441:23
#15 0x000060969a1f09a2 llvm::FPPassManager::runOnModule(llvm::Module&) /mnt/DevDrive/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1487:16
#16 0x000060969a1ec43b (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /mnt/DevDrive/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1556:23
#17 0x000060969a1ebfb1 llvm::legacy::PassManagerImpl::run(llvm::Module&) /mnt/DevDrive/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:541:16
#18 0x000060969a1f0c81 llvm::legacy::PassManager::run(llvm::Module&) /mnt/DevDrive/projects/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1683:3
#19 0x0000609696bf0747 compileModule(char**, llvm::LLVMContext&) /mnt/DevDrive/projects/llvm-project/llvm/tools/llc/llc.cpp:741:9
#20 0x0000609696bee8f5 main /mnt/DevDrive/projects/llvm-project/llvm/tools/llc/llc.cpp:408:13
#21 0x0000701f3f429d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#22 0x0000701f3f429e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)

Originally posted by @farzonl in #87952 (comment)

@Keenuts for awareness.

[VyacheslavLevytskyy]

@farzonl @Keenuts I don't think it's an issue. We can't pass bit width other than 32 with IDRegClass, because this register class is defined to hold 32 bit width values, please see

llvm-project/llvm/lib/Target/SPIRV/SPIRVRegisterInfo.td

Line 34 in 673da8c

def ID : RegisterClass<"SPIRV", [i32], 32, (add ID0)>;

As a more general note, bit width for integers in SPIR-V backend works in a consistent manner when we are talking about generated instructions. Otherwise, in case of low-level types, registers, register classes and register banks, we are dealing with an abstraction that doesn't relate LLVM low-level types and user data types, but rather is using low-level types for Tablegen-driven instruction selection.

[farzonl]

@VyacheslavLevytskyy is this case a bug waiting to happen then:

https://github.com/llvm/llvm-project/blob/45eabd1362527d1b3a27a90f7479865785b763ee/llvm/lib/Target/SPIRV/SPIRVGlobalRegistry.cpp#L301C1-L303C62

I created the bug to track the todo I saw in the code base and there was some evidence to suggest bit width was important here. If that isn't the case then this ticket should change to remove the todos and to fix the case I linked above to just do 32 bit width.

[VyacheslavLevytskyy]

@farzonl I agree that there is a space for improvements here. However, the context is wider than just this example, and my comment above was related mainly to the incorrect "crash" classification of this issue. It's not a crash, I'd remove this label as confusing, but rather a part of the bigger question -- how do we use LLT with Tablegen instruction selection. I'd say that we may want to create a bigger TODO item (probably, a lower priority one) to improve usage of Tablegen for instruction selection, including this particular case of bit width in LLT.