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

[David Blaikie]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131015/d089362f/attachment.html>