[llvm] [mlir] [mlir][EmitC] Add MathToEmitC pass for math function lowering to EmitC (PR #113799)

[Gil Rapaport via llvm-commits]

================
@@ -62,4 +62,13 @@ def EmitC_OpaqueAttr : EmitC_Attr<"Opaque", "opaque"> {
 
 def EmitC_OpaqueOrTypedAttr : AnyAttrOf<[EmitC_OpaqueAttr, TypedAttrInterface]>;
 
+def MathToEmitCLanguageTarget : I32EnumAttr<"MathToEmitCLanguageTarget",
+  "Specifies the language target for generating callees.", [
+    I32EnumAttrCase<"C", 0, "Use C-style function names">,
+    I32EnumAttrCase<"CPP", 1, "Use C++-style function names">
+  ]> {
+  let cppNamespace = "::mlir::emitc";
+}
----------------
aniragil wrote:

I wonder if we could take advantage of this use case to introduce a more general attribute attached to the module, e.g.  `EmitCTarget`/`EmitCTargetLanguage`, to be used consistently by lowering passes and the translator where distinct C variants require different lowering, module-level verification or syntax, e.g. 

* Multiple return values are currently lowered to C++ has `std::tuple`, unavailable in other C variants.
* OpenCL-C defines several address spaces, other C variants don't.
* OpenCL-C has native vector types (to some extent), C doesn't.
* C++ has templates, other C variants don't.
* C/C++ support function pointers and recursion, OpenCL-C doesn't.

An alternative to such an attribute might be target-language module ops, e.g. EmitC::C99ModuleOp.

>With the current PR we have "C" and "CPP" as possible targets (I actually would prefer lowercase here). What about >specifying language standard instead? While not having a demand myself right now, I think adding the option to add c23 to e.g. emit fabsd32 could be nice (?). Any (further) opinions on this?

+1
Would be good to enumerate all standard C/C++ versions and let each pass differentiate its lowering as needed.

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