[DebugInfo@O2][Dexter] Vectorized loop presents constant-valued iterator to debugger

[Quuxplusone]

Bugzilla Link	PR39018
Status	NEW
Importance	P normal
Reported by	Jeremy Morse (jeremy.morse.llvm@gmail.com)
Reported on	2018-09-20 08:08:25 -0700
Last modified on	2020-11-05 03:41:32 -0800
Version	trunk
Hardware	PC Linux
CC	chackz0x12@gmail.com, chris.jackson@sony.com, greg.bedwell@sony.com, international.phantom@gmail.com, llvm-bugs@lists.llvm.org, paul.robinson@am.sony.com
Fixed by commit(s)
Attachments
Blocks	PR38768
Blocked by
See also

The vectorized loop below has a constant valued iterator according to debug
info in optimised programs. Using clang/llvm r342527, compiling "-O2 -g -fno-
inline" targeting x86_64, and running under gdb or lldb, printing 'i' on any
iteration of the first loop will yield the value zero. Obviously this is
misleading to the developer.

Running dwarfdump shows that there's just one debug location for 'i', where
it's assigned the constant value of zero. My feeling is that the vectorizer
discards all debug data in the loop, leaving only one dbg.value call in the
program (the constant initializer) and no indication of what the liveness of
that value is. [This class of bug is likely to be a theme].

I imagine putting dbg.value(undef, ...) in the vectorized loop might fix this,
however I'm not really familiar with the vectorizer at all.

The problem replicates if you add -fno-unroll-loops to the command line, and
gives you assembly you have a chance of understanding.

-------->8--------
#include <string.h>

#define BUFSZ 192

int
main()
{
  int foo[BUFSZ];
  int bar[BUFSZ];

  memset(foo, 0, sizeof(foo));
  memset(bar, 1, sizeof(bar));

  for (int i = 0; i < BUFSZ; i++)
    foo[i] += bar[i];

  unsigned int sum = 0;
  for (int j; j < BUFSZ; j++)
    sum += foo[j];

  return sum;
}
--------8<--------

[Quuxplusone]

The 'j' variable at the end there should be initialized to zero; this doesn't affect the ticket [I was playing with some different constructs and forgot to revert before uploading, sorry for any confusion].

[Quuxplusone]

Addressing this wi th https://reviews.llvm.org/D90418.

The initial diff is to prevent misleading information being present, I intend to provide an additional patch that ties the original induction variable to the vectorised widths and iterations so that it can hold a meaningful value.