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

[Sergio Afonso via flang-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:

@Leporacanthicus thanks for the feedback! I didn't think about testing function declarations, so I'll make some tests and let you know. If that doesn't work, then it might be a reason to go for the pass-based approach depending on how difficult that case would be to address in lowering.

About your second concern, I think it should be fine as it is right now. We can cache the target CPU and features strings somewhere in the bridge to avoid calling `TargetMachine::getTarget{CPU, FeatureString}` for each function, but these functions just return cached `StringRef`s, so I think it's probably not a problem.

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