Retrieving the original C/C++ variable name for an LLVM value - disabling opt pass indvars

Hello.
     Could you please tell me if disabling the indvars pass is a good idea (when still considering running -O3, including loop vectorization). So far I didn't get any errors in the entire LLVM flow, but I'd like to get a second opinion.

     The reason I ask this is that for the C program below (for example), when using -O3 I lose the name for the C variable i, because of the indvars pass (http://llvm.org/docs/Passes.html#indvars-canonicalize-induction-variables), which replaces it with indvars.iv in the LLVM program obtained from opt:
       typedef short VAL_TYPE;
       typedef short SPMV_TYPE;
       void SpMV(int M, SPMV_TYPE *row_ptr, SPMV_TYPE *colind, VAL_TYPE *data, VAL_TYPE *x) {
           int i, j, colCrt;
           VAL_TYPE zi, z[VECTOR_LEN]; /* result vector of SpMV */

           for (i = 0; i < M; i++) {
               z[i] = 0.0;
               for (j = row_ptr[i]; j < row_ptr[i + 1]; j++) {
                   z[i] += data[j] * x[colind[j]];
               }
           }
           for (i = 0; i < M; i++)
               printf("z[%d] = %.3f\n", i, z[i]);
       }

     Since it is very difficult to retrieve the original C name of the variable(s) after the indvars pass and also I couldn't find a decent way to disable running the indvars pass in opt, I have manually commented out the pass in lib/Transforms/IPO/PassManagerBuilder.cpp - the line registering it: "MPM.add(createIndVarSimplifyPass()); // Canonicalize indvars".

     After disabling it, I obtain an LLVM program that contains an equivalent LLVM variable %i.026 (the compiler adds suffix ".026" to the C var name) corresponding simply to the C var i - below follows a meaningful excerpt:
       for.body: ; preds = %for.body.preheader, %for.cond.loopexit
         %1 = phi i16 [ %2, %for.cond.loopexit ], [ %.pre, %for.body.preheader ], !dbg !43
         %i.026 = phi i32 [ %add, %for.cond.loopexit ], [ 0, %for.body.preheader ]
         %idxprom = sext i32 %i.026 to i64, !dbg !50
         %arrayidx = getelementptr inbounds [3 x i16], [3 x i16]* %z, i64 0, i64 %idxprom, !dbg !50
         store i16 0, i16* %arrayidx, align 2, !dbg !61, !tbaa !46
   tail call void @llvm.dbg.value(metadata i32 %conv, i64 0, metadata !22, metadata !29), !dbg !62
         %add = add nsw i32 %i.026, 1, !dbg !63
         %idxprom4 = sext i32 %add to i64, !dbg !64
         %arrayidx5 = getelementptr inbounds i16, i16* %row_ptr, i64 %idxprom4, !dbg !64
         %2 = load i16, i16* %arrayidx5, align 2, !dbg !64, !tbaa !46
         %cmp723 = icmp slt i16 %1, %2, !dbg !65
         br i1 %cmp723, label %for.body9.lr.ph, label %for.cond.loopexit, !dbg !54

   Thank you,
     Alex

Hi Alex,

> Hello.
> Could you please tell me if disabling the indvars pass is a good idea
> (when still considering running -O3, including loop vectorization). So
> far I didn't get any errors in the entire LLVM flow, but I'd like to get
> a second opinion.

You need to benchmark your application before deciding if disabling
indvars is a good idea or not, but I can tell you this: variable names
preservation at the IR level is usually a _bad_ reason to disable
*any* pass. :slight_smile:

Why do you care about preserving variable names in the generated IR?
Can you get the information you want some other way (like DWARF
debug info)?

-- Sanjoy