[llvm] [SPIRV] Support for SPV_INTEL_cluster_attributes extension (PR #131593)

[via llvm-commits]

================
@@ -1976,6 +1980,38 @@ static void handleMIFlagDecoration(MachineInstr &I, const SPIRVSubtarget &ST,
   buildOpDecorate(DstReg, I, TII, SPIRV::Decoration::FPFastMathMode, {FMFlags});
 }
 
+static void handleFunctionDecoration(MachineInstr &MI, const SPIRVSubtarget &ST,
+                                     const SPIRVInstrInfo &TII,
+                                     SPIRV::ModuleAnalysisInfo &MAI,
+                                     llvm::Module::const_iterator F) {
+  Register FuncReg = MI.getOperand(0).getReg();
+  llvm::SmallVector<std::pair<unsigned int, llvm::MDNode *>> MetaDataList;
+
+  // Add function-level decorations based on metadata
+  F->getAllMetadata(MetaDataList);
+  for (auto &MetaData : MetaDataList) {
+    if (MetaData.second == F->getMetadata("stall_enable") ||
+        MetaData.second == F->getMetadata("stall_free")) {
----------------
EbinJose2002 wrote:

> > Should the !spirv.Decorations metadata be expected to already exist in the LLVM IR (i.e., injected by the frontend or via an earlier pass), or am I expected to modify the frontend to emit this?
> 
> As I have previously stated in [#134352 (comment)](https://github.com/llvm/llvm-project/pull/134352#discussion_r2075542078) - I don't really understand the end goal to give a precise and educated suggestion. So this question should be readdressed to your internship curator, what are you going to do with these extensions (I'm judging that there is one from your reply: "Actually I was implementing this extension as part of an internship project."). My point is: that it's better not to use internal to intel/llvm metadata. If the goal is just to modify SPIR-V backend that way, that it can emit SPV_INTEL_cluster_attributes - spirv.Decorations metadata is the way to go. Otherwise - if there are further plans to use these extensions, then it's still better to expect spirv.Decorations in the backend (and target it by the frontend) unless proven otherwise.
> 
> Also, I can't tell for sure as I haven't tested it, but my expectation is that nowadays llvm-spirv translator supports SPV_INTEL_cluster_attributes via spirv.Decorations metadata implicitly.

Actually there is no particular use for this extension for us as of now. This was part of being familiar with llvm-project repo. So I tried to implement the missing extensions the same way they are handled in the translator. (Also the translator is using "stall_enable" and "stall_free" metadata to handle the extension)
So should I proceed with implementing the extension by modifying the frontend?

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