================
@@ -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
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
