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

Gil Rapaport llvmlistbot at llvm.org
Wed Apr 30 12:30:01 PDT 2025


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

> 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?

Sure, since the letter to stop at is quite arbitrary `u` makes as good a choice as any (to me btw it looks more natural to have `i..t` and then numbered `u0`, `u1`).

> 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.

Sure, we can later narrow the range further if needed.

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


More information about the Mlir-commits mailing list