[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