[Mlir-commits] [mlir] [MLIR][IRDL] Relax the restrictions on IRDL-defined names (PR #187911)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Mon Mar 23 02:24:23 PDT 2026
================
@@ -65,16 +65,46 @@ static std::string joinNameList(llvm::ArrayRef<std::string> names) {
return nameArray;
}
+// Convert a dialect/operation/type/attribute name to a valid identifier in C++.
+// The conversion is done by removing dots, underscores and dollar signs and
+// capitalizing the following character. For example, `name.with.dots` will be
+// converted to `nameWithDots` with `capitalizeFirst = false`.
+static std::string toCppName(StringRef input, bool capitalizeFirst = false) {
+ if (input.empty())
+ return "";
+
+ std::string output;
+ output.reserve(input.size());
+
+ // Push the first character, capatilizing if necessary.
+ if (capitalizeFirst && std::islower(input.front()))
+ output.push_back(llvm::toUpper(input.front()));
+ else
+ output.push_back(input.front());
+
+ // Walk the input converting any `*[._$]+[a-z]` snake case into `*[A-Z]`
+ // camelCase.
+ bool isSpecial = false;
+ for (char c : input.drop_front()) {
+ if (c == '_' || c == '.' || c == '$')
+ isSpecial = true;
+ else if (isSpecial) {
+ output.push_back(llvm::toUpper(c));
----------------
PragmaTwice wrote:
I feel that this is a pursuit of "unnecessary completeness". I believe that no "sane" people will define both a `vector.load` operation and a `vector_load` operation in one dialect, so this kind of mapping (IIUC you want a bijection) beautiful in math but meaningless in reality. What make it even worse is that, for both `vector.load` and `vector_load`, people may want a same C++ type name like `VectorLoadOp`. A bijection will make the name worse.
BTW I'm not a user of irdl-to-cpp (we only care about dynamic loading part of IRDL) so the problem of me is that it blocks people (like @rolfmorel) using dots in operation names (these naming restrictions are weird and meaningless for people who don't use `irdl-to-cpp`).
https://github.com/llvm/llvm-project/pull/187911
More information about the Mlir-commits
mailing list