[PATCH] LowerDbgDeclare - get rid of redundant dbg.values when an alloca survives optimization

[Adrian Prantl]

Looks like you answered that question yourself. Thanks!
; RUN: opt -instcombine %s -verify -S -asm-verbose | FileCheck %s
works just fine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Debug-info-Reduce-the-amount-of-redundant-debug-info.patch
Type: application/octet-stream
Size: 6619 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131015/a1fb7eb6/attachment.obj>
-------------- next part --------------


-- adrian

On Oct 15, 2013, at 13:30, David Blaikie <dblaikie at gmail.com> wrote:

> 
> 
> 
> On Tue, Oct 15, 2013 at 1:06 PM, Adrian Prantl <aprantl at apple.com> wrote:
> You still need to pass -O2 to clang.
> 
> Right - but what I mean is, in your test case, rather than running -O2, could you run only the specific passes that cause the transformation to occur that's concerned? See, for example, the various tests in test/Transforms/*, each of which uses opt arguments to run just the transformation it's testing (-instcombine in the InstCombine tests, -globalopt in the GlobalOpt tests, etc). You could even put this test in the directory for the tests for the transform in question. 
> 
> It looks like it's InstCombine, since that's the only caller of this function - but you might need to run the IR through some other transformations first (and checkin the result of that) before passing it to InstCombine in the test.
>  
> 
> -- adrian
> 
> On Oct 15, 2013, at 13:01, David Blaikie <dblaikie at gmail.com> wrote:
> 
> >
> >
> >
> > On Tue, Oct 15, 2013 at 11:46 AM, Adrian Prantl <aprantl at apple.com> wrote:
> >
> > On Oct 15, 2013, at 11:42, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > > Could you attach/paste the IR obtained without your change? I'm curious to see what dbg.values are produced.
> >
> > ; Function Attrs: nounwind ssp uwtable
> > define void @foo() #0 {
> >   %offset = alloca i64, align 8
> >   call void @llvm.dbg.declare(metadata !{i64* %offset}, metadata !10), !dbg !13
> >   call void @llvm.dbg.value(metadata !14, i64 0, metadata !10), !dbg !13
> >   store i64 0, i64* %offset, align 8, !dbg !13, !tbaa !15
> >   %1 = call i32 @bar(i64* %offset, i64 0) #3, !dbg !19
> >   %2 = icmp eq i32 %1, 0, !dbg !19
> >   br i1 %2, label %6, label %3, !dbg !19
> >
> > ; <label>:3                                       ; preds = %0
> > ; -----> This is the one I care about:
> >   call void @llvm.dbg.value(metadata !{i64* %offset}, i64 0, metadata !10), !dbg !21
> >   %4 = load i64* %offset, align 8, !dbg !21, !tbaa !15
> >   %5 = call i32 @bar(i64* %offset, i64 %4) #3, !dbg !21
> >   br label %6, !dbg !21
> >
> > ; <label>:6                                       ; preds = %3, %0
> >   ret void, !dbg !22
> > }
> >
> > > & a little bit of 'asking for a pony' - but is there one specific optimization you could run to demonstrate this problem rather than all of -O2?
> >
> > No ponies, unfortunately. The specific optimization _is_ LowerDbgDeclare and it usually gets run by clang even if you go straight to -emit-llvm.
> >
> > Sorry, I'm not sure I follow. When I run clang -g -O0 -S -emit-llvm on the source you listed (and without your change applied) I get one dbg.declare, no dbg.values). So I don't know what you mean by "usually gets run by clang even if you go straight to -emit-llvm" - if that were true, wouldn't I expect to see the spurious dbg.values you described in the output of -g -O0 -S -emit-llvm?
> 
>