[PATCH] D25872: [IndVarSimplify][DebugLoc] When widening the IV increment, correctly set the debug loc.
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Fri Oct 21 07:54:39 PDT 2016
I assume we would see this is a pure debug quality bug if you split the for
loop header over multiple lines? (so it wasn't just a discriminator bug)?
Which instruction/part of the loop header is it taking the line 4/disc 1
On Fri, Oct 21, 2016 at 7:34 AM Andrea Di Biagio <andrea.dibiagio at gmail.com>
> andreadb created this revision.
> andreadb added reviewers: aprantl, probinson, wolfgangp, dblaikie,
> andreadb added a subscriber: llvm-commits.
> Herald added a subscriber: mehdi_amini.
> When indvars creates a wide induction variable, the debug location for the
> loop increment is incorrect (see below):
> extern int foo(int);
> int bar(int x, int *a)
> for (int i = 0; i < x; ++i) // line 4
> a[i] = foo(i);
> return a;
> Before indvars is run, the IV (induction variable) increment is performed
> in the loop latch at line 4:
> %inc = add nsw i32 %i.06, 1, !dbg !13
> Where, %i.06 is our IV, and !dbg !13 is a DILocation which refers to line
> 4, discriminator 2.
> After indvars is run, our IV is expanded into:
> %indvars.iv = phi i64 [ %indvars.iv.next, %for.inc ], [ 0, %
> In particular, %indvars.iv.next is defined by instruction:
> %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1, !dbg !9
> However, !dbg !9 is the debug loc for line 4, discriminator 1. It should
> have been line 4, discriminator 2.
> This patch fixes the issue by propagating the correct debug location from
> the original loop increment instruction to the new widened increment.
> Please let me know if okay to commit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits