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

Adrian Prantl aprantl at apple.com
Tue Oct 15 13:06:08 PDT 2013


You still need to pass -O2 to clang.

-- 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?




More information about the llvm-commits mailing list