[llvm-branch-commits] [flang] [Flang][Lower] Attach target_cpu and target_features attributes to MLIR functions (PR #78289)

[Sergio Afonso via llvm-branch-commits]

================
@@ -4290,6 +4291,18 @@ class FirConverter : public Fortran::lower::AbstractConverter {
     assert(blockId == 0 && "invalid blockId");
     assert(activeConstructStack.empty() && "invalid construct stack state");
 
+    // Set target_cpu and target_features attributes to be passed through to the
+    // llvm.func operation during lowering.
+    const llvm::TargetMachine &targetMachine = bridge.getTargetMachine();
+    if (auto targetCPU = targetMachine.getTargetCPU(); !targetCPU.empty())
+      func->setAttr("target_cpu",
+                    mlir::StringAttr::get(func.getContext(), targetCPU));
+
+    if (auto targetFeatures = targetMachine.getTargetFeatureString();
+        !targetFeatures.empty())
+      func->setAttr("target_features", mlir::LLVM::TargetFeaturesAttr::get(
+                                           func.getContext(), targetFeatures));
----------------
skatrak wrote:

@kiranchandramohan at this time, these function attributes would be added with the only purpose of being forwarded to the LLVM dialect and from there being translated into LLVM IR function attributes, so as you say it would be possible to delay their introduction to a later pass rather than doing it directly in lowering.

However, in my opinion, this is general information in the same category as the target triple, kind mapping or data layout that could be at some point needed earlier in the compilation flow, just like these other attributes are. I agree with @kparzysz that having this information available in the lowering bridge doesn't really introduce new dependencies, so I don't currently see any clear downsides. The benefit of this approach is that this information is available as soon as possible and we don't introduce intermediate MLIR representations where this information that is known in advance can't be accessed.

So, I think at the moment this is still my preferred approach, though I'm happy to change it if there are any other aspects I've missed or if the alternative seems to be generally preferred by the community.

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