llvm dev - Aug 2016 - 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,

Alex Susu via llvm-dev wrote:
 > 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. :)

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