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

[Niklas Degener]

================
@@ -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') {
----------------
ndegener-amd wrote:

In practice, the 14 nesting levels to reach `v` should rarely be necessary. But emitc does not restrict deep nesting, so it should be handled properly. I had hope, that the differentiation between regular vars (v0) and induction vars in the context of loop nests (v_0) would be enough. It would also be possible to start the z-continuation already at u. So the scheme would be `i..u` and afterwards `u0, u1, ..., uX`. What do you think of this?
Regarding other variable types: As there are also other changes to naming of special types possible (e.g. references), I would not keep it in mind for now.

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