[Mlir-commits] [mlir] [MLIR][Target/Cpp] Natural induction variable naming. (PR #136102)

[Gil Rapaport]

================
@@ -1245,7 +1278,29 @@ StringRef CppEmitter::getOrCreateName(Value val) {
     assert(!hasDeferredEmission(val.getDefiningOp()) &&
            "cacheDeferredOpResult should have been called on this value, "
            "update the emitOperation function.");
-    valueMapper.insert(val, formatv("v{0}", ++valueInScopeCount.top()));
+
+    valueMapper.insert(val, formatv("v{0}", ++valueCount));
+  }
+  return *valueMapper.begin(val);
+}
+
+/// Return the existing or a new name for a loop induction variable Value.
+/// Loop induction variables follow natural naming: i, j, k,...
+StringRef CppEmitter::getOrCreateName(emitc::ForOp forOp) {
+  Value val = forOp.getInductionVar();
+
+  if (!valueMapper.count(val)) {
+
+    int64_t identifier = 'i' + loopNestingLevel;
+
+    if (identifier >= 'i' && identifier <= 'z') {
+      valueMapper.insert(val,
+                         formatv("{0}_{1}", (char)identifier, ++valueCount));
----------------
aniragil wrote:

Function-level numbering kind of makes sense as the numbering scheme for variables that carry no scope-related semantics (or any other semantics, which is why they're all named `v`).
Induction variables OTOH are loop-scoped, so function-level numbering them seems unnatural to me (I don't define `int i0` and `int i1` as induction variables when writing sibling loops but rather define `int i` twice). It also leads to less readable expressions, e.g. `v89[i22 + 3][j74 * 2][k38 - 1]` vs `v89[i + 3][j * 2][k - 1]`). @simon-camp, @marbre, WDYT?

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