<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 18, 2013 at 10:12 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any final verdict for this change?<br></blockquote><div><br></div><div>I'm not really familiar with this stuff to provide a 'final verdict' as it were, but I'll ask some questions anyway...<br>
<br>Is this the correct test? Is it possible that the variable might be reconstituted around the call, rather than kept live for the entire range?<br>If there are things that prevent the alloca from being elided, are those things enshrined in a test somewhere that we could reuse, rather than reimplementing one part of them?<br>
<br>(& if you felt like it, you could probably use find_if to write that loop - but that might not add a lot to the situation (& not sure it'll work with all the template machinery of 'isa'))</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- adrian<br>
<div><div class="h5"><br>
<br>
On Oct 15, 2013, at 13:53, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
<br>
> Looks like you answered that question yourself. Thanks!<br>
> ; RUN: opt -instcombine %s -verify -S -asm-verbose | FileCheck %s<br>
> works just fine.<br>
><br>
</div></div>> <0001-Debug-info-Reduce-the-amount-of-redundant-debug-info.patch><br>
><br>
> -- adrian<br>
<div class="HOEnZb"><div class="h5">><br>
> On Oct 15, 2013, at 13:30, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>><br>
>> On Tue, Oct 15, 2013 at 1:06 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>> You still need to pass -O2 to clang.<br>
>><br>
>> 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.<br>

>><br>
>> 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.<br>

>><br>
>><br>
>> -- adrian<br>
>><br>
>> On Oct 15, 2013, at 13:01, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Oct 15, 2013 at 11:46 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
>>><br>
>>> On Oct 15, 2013, at 11:42, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>>><br>
>>>> Could you attach/paste the IR obtained without your change? I'm curious to see what dbg.values are produced.<br>
>>><br>
>>> ; Function Attrs: nounwind ssp uwtable<br>
>>> define void @foo() #0 {<br>
>>>  %offset = alloca i64, align 8<br>
>>>  call void @llvm.dbg.declare(metadata !{i64* %offset}, metadata !10), !dbg !13<br>
>>>  call void @llvm.dbg.value(metadata !14, i64 0, metadata !10), !dbg !13<br>
>>>  store i64 0, i64* %offset, align 8, !dbg !13, !tbaa !15<br>
>>>  %1 = call i32 @bar(i64* %offset, i64 0) #3, !dbg !19<br>
>>>  %2 = icmp eq i32 %1, 0, !dbg !19<br>
>>>  br i1 %2, label %6, label %3, !dbg !19<br>
>>><br>
>>> ; <label>:3                                       ; preds = %0<br>
>>> ; -----> This is the one I care about:<br>
>>>  call void @llvm.dbg.value(metadata !{i64* %offset}, i64 0, metadata !10), !dbg !21<br>
>>>  %4 = load i64* %offset, align 8, !dbg !21, !tbaa !15<br>
>>>  %5 = call i32 @bar(i64* %offset, i64 %4) #3, !dbg !21<br>
>>>  br label %6, !dbg !21<br>
>>><br>
>>> ; <label>:6                                       ; preds = %3, %0<br>
>>>  ret void, !dbg !22<br>
>>> }<br>
>>><br>
>>>> & 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?<br>
>>><br>
>>> No ponies, unfortunately. The specific optimization _is_ LowerDbgDeclare and it usually gets run by clang even if you go straight to -emit-llvm.<br>
>>><br>
>>> 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?<br>

>><br>
>><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
</div></div></blockquote></div><br></div></div>