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

[llvmlistbot at llvm.org]

================
@@ -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));
----------------
jeanPerier wrote:

I am in favor of delaying this to something like codegen (or better, the target rewrite pass) based on Kiran point that functions may be generated during FIR to FIR passes and that this is a lot of noise.

Some target specific aspect are unavoidable in high level representation because it is needed for Fortran semantics (e.g., the data layout), but it does not mean we should start doing/adding a lot of target specific aspects in the IR before it is actually needed.

I would also prefer passing the target_cpu/target_features as strings to the target rewrite pass, the TargetMachine is not an easy object to come by, and makes testing dependent on the available targets in the LLVM build.

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