<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 11, 2016 at 5:35 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jan 11, 2016 at 4:59 PM, Cong Hou <<a href="mailto:congh@google.com">congh@google.com</a>> wrote:<br>
> congh added a comment.<br>
><br>
> In <a href="http://reviews.llvm.org/D11393#323944" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11393#323944</a>, @davidxl wrote:<br>
><br>
>> Restart discussion on this thread:<br>
>><br>
>> For the motivating example where two conditional branches have different targets,<br>
>><br>
>> jne   .BB1<br>
>>  jnp  .BB2<br>
>>  .BB1:<br>
>>  ...<br>
>>  .BB2:<br>
>>  ...<br>
>><br>
>> Is it possible to teach AnalyzeBranch to recognize the pattern -- with opcode COND_NE_OR_P ?<br>
><br>
><br>
> Yes, I think this is done in this patch. Or do I misunderstand what you mean?<br>
<br>
</span>The patch removes the branch condition reversing optimization in<br>
AnalyzeBranch -- is that needed? For the motivating example, no new<br>
opcode seems to be needed either ..<br></blockquote><div><br></div><div>I think branch condition reversing optimization in AnalyzeBranch is unnecessary: we will do it in block-placement anyway. And just as you once said, it is a bad idea to modify the branch in a function called AnalyzeBranch(), which seems a readonly function.</div><div><br></div><div>Cong</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
David<br>
<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D11393" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11393</a><br>
><br>
><br>
><br>
</blockquote></div><br></div></div>