[Mlir-commits] [flang] [mlir] [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:

> We already get the target machine at this point, so we may extract all that we're going to need from it, until having it again becomes necessary (generation of LLVM IR?).

The issue is that this implies that every func.func created after the bridge/not in this very spot would not have these attributes while they should. So this would push the requirements of such target attribute setting to every spot creating fun.func. We could use a centralized helper, but you would still need to thread the info to the place calling it, and you cannot easily enforce that it is being used (especially if some FIR external passes are used).

So, much safer/consistent to do it in a pass IMHO.

I understand your point about self-contained module, and I am not opposed adding these attributes to the module op until we are ready to add them on the func.func (that is, before codegen when we should not emit new func.func), and to retrieve them from here instead of the driver.

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