<div dir="ltr">Thanks!<div><br></div><div>I tried the new test case, the assembly is now different, but still seem equivalent:</div><div><br></div><div><div>#diff loop-rotate.s ../new/loop-rotate.s</div><div>47c47</div><div>< <span class="gmail-Apple-tab-span" style="white-space:pre">  </span>.loc<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>1 0 3 is_stmt 0 discriminator 1 # loop-rotate.c:0:3</div><div>---</div><div>> <span class="gmail-Apple-tab-span" style="white-space:pre">     </span>.loc<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>1 16 13                 # loop-rotate.c:16:13</div><div>51d50</div><div>< <span class="gmail-Apple-tab-span" style="white-space:pre"> </span>.loc<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>1 16 13 is_stmt 1       # loop-rotate.c:16:13</div><div>103a103</div><div>> <span class="gmail-Apple-tab-span" style="white-space:pre">    </span>xorl<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>%ebp, %ebp</div><div>106d105</div><div>< <span class="gmail-Apple-tab-span" style="white-space:pre">  </span>xorl<span class="gmail-Apple-tab-span" style="white-space:pre">  </span>%ebp, %ebp</div><div>193c192</div><div>< <span class="gmail-Apple-tab-span" style="white-space:pre">  </span>.asciz<span class="gmail-Apple-tab-span" style="white-space:pre">        </span>"/ssd/llvm/build.gccopt/1" # string offset=69</div><div>---</div><div>> <span class="gmail-Apple-tab-span" style="white-space:pre"> </span>.asciz<span class="gmail-Apple-tab-span" style="white-space:pre">        </span>"/ssd/llvm/build.gccopt/2" # string offset=69</div></div><div><br></div><div>Dehao</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 10:38 AM, Xin Tong <span dir="ltr"><<a href="mailto:trent.xin.tong@gmail.com" target="_blank">trent.xin.tong@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dehao. I am putting up a new example, the command line to reproduce is<br>
the same. The example before suffers from block merging in<br>
BranchFolding in downstream in llc. Because there is no<br>
simplifications done to peeled block. With this example, we will see<br>
that we overpeeled the loop due to not updating the metadata properly<br>
after rotation.<br>
<br>
Thanks<br>
-Xin<br>
<br>
// looprotate.c<br>
const int looparr[4] = {1,2,3,4};<br>
int g = 0;<br>
<br>
__attribute__((noinline)) void call_me(int loopvalue) {<br>
  g = loopvalue;<br>
<span class="">}<br>
<br>
<br>
// Invoke call_me once when done_call is false.<br>
// This is a case where the loop executes once everytime the function<br>
</span>// is called.<br>
<br>
__attribute__((noinline)) void always_call(int max) {<br>
  for (int i = 0; i < max; ++i)<br>
    call_me(looparr[i]);<br>
<span class="">}<br>
<br>
<br>
// Invoke call_me once when done_call is false and index is odd.<br>
// This is a case where the loop does not execute even once half of the<br>
// time because of the index.<br>
</span>__attribute__((noinline)) void call_on_odd(int max, int index) {<br>
  for (int i = 0; i < max && index % 2; ++i)<br>
    call_me(looparr[max]);<br>
}<br>
<br>
<br>
int main() {<br>
  const int max = 1;<br>
<span class="">  for (int i = 0; i < 128; ++i) {<br>
</span>    always_call(max);<br>
    call_on_odd(max, i);<br>
  }<br>
  return 0;<br>
<div class="HOEnZb"><div class="h5">}<br>
<br>
On Fri, Jan 13, 2017 at 9:36 AM, Xin Tong <<a href="mailto:trent.xin.tong@gmail.com">trent.xin.tong@gmail.com</a>> wrote:<br>
> On Fri, Jan 13, 2017 at 9:34 AM, Dehao Chen <<a href="mailto:danielcdh@gmail.com">danielcdh@gmail.com</a>> wrote:<br>
>> OK, but the with the new patch, the generated assembly file is identical<br>
>> with the assembly generated by a clean compiler (without the patch).<br>
>><br>
>> Dehao<br>
><br>
> Yes, there is something in branchfolding in llc that folds away some<br>
> of the branches. I am looking at why.<br>
><br>
> -Xin<br>
>><br>
>> On Fri, Jan 13, 2017 at 9:21 AM, Xin Tong <<a href="mailto:trent.xin.tong@gmail.com">trent.xin.tong@gmail.com</a>> wrote:<br>
>>><br>
>>> On Fri, Jan 13, 2017 at 7:36 AM, Dehao Chen via Phabricator<br>
>>> <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br>
>>> > danielcdh added a comment.<br>
>>> ><br>
>>> > Looks like this patch will make the "always call" worse:<br>
>>> ><br>
>>> > Without this patch:<br>
>>> ><br>
>>> >   pushq   %rbx<br>
>>> >   movq    %rdi, %rbx<br>
>>> >   cmpl    $0, (%rbx)<br>
>>> >   jne     .LBB1_3<br>
>>> ><br>
>>> > .LBB1_1:                                # =>This Inner Loop Header:<br>
>>> > Depth=1<br>
>>> ><br>
>>> >   movq    %rbx, %rdi<br>
>>> >   callq   call_me<br>
>>> >   cmpl    $0, (%rbx)<br>
>>> >   je      .LBB1_1<br>
>>> ><br>
>>> > .LBB1_3:<br>
>>> ><br>
>>> >   popq    %rbx<br>
>>> >   retq<br>
>>> ><br>
>>> > With this patch:<br>
>>> ><br>
>>> >   pushq   %rbx<br>
>>> >   movq    %rdi, %rbx<br>
>>> >   cmpl    $0, (%rbx)<br>
>>> >   je      .LBB1_1<br>
>>> ><br>
>>> > .LBB1_3:<br>
>>> ><br>
>>> >   popq    %rbx<br>
>>> >   retq<br>
>>> ><br>
>>> > .LBB1_1:                                # =>This Inner Loop Header:<br>
>>> > Depth=1<br>
>>> ><br>
>>> >   movq    %rbx, %rdi<br>
>>> >   callq   call_me<br>
>>> >   cmpl    $0, (%rbx)<br>
>>> >   jne     .LBB1_3<br>
>>> >   jmp     .LBB1_1<br>
>>> ><br>
>>> > As the trip count of this loop is always 1, the first code will have no<br>
>>> > taken branches, while with this patch, it will have 2 taken branches.<br>
>>> ><br>
>>> ><br>
>>> > <a href="https://reviews.llvm.org/D28593" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D28593</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>><br>
>>> Sorry there is a mistaken updating the branch weight for the guard<br>
>>> block. I fixed it. what i said before still hold true.<br>
>>> -Xin<br>
>><br>
>><br>
</div></div></blockquote></div><br></div>