<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 12, 2010, at 6:24 PM, Bill Wendling wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Apr 12, 2010, at 5:18 PM, Chris Lattner wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> // If the prior block branches here on true and somewhere else on false, and<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> // if the branch condition is reversible, reverse the branch to create a<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> // fall-through.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> if (PriorTBB == MBB) {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">   SmallVector<MachineOperand, 4> NewPriorCond(PriorCond);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">   if (!TII->ReverseBranchCondition(NewPriorCond)) {<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     TII->RemoveBranch(PrevBB);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     TII->InsertBranch(PrevBB, PriorFBB, 0, NewPriorCond);<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     MadeChange = true;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     ++NumBranchOpts;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">     goto ReoptimizeBlock;<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">   }<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> }<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Why doesn't it work in this case?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I was curious too. CodeGenPrepare has split a critical edge for a PHI<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">node, however after register allocation it turns out that no copy was<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">needed, so the jmp is actually in a separate basic block from the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">jne, jp.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In that case, branch folding should be removing the block that consists of only an unconditional branch:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">     // If this block is just an unconditional branch to CurTBB, we can<br></blockquote><blockquote type="cite">     // usually completely eliminate the block.  The only case we cannot<br></blockquote><blockquote type="cite">     // completely eliminate the block is when the block before this one<br></blockquote><blockquote type="cite">     // falls through into MBB and we can't understand the prior block's branch<br></blockquote><blockquote type="cite">     // condition.<br></blockquote><blockquote type="cite">     if (MBB->empty()) {<br></blockquote><blockquote type="cite">        <too long to quote, but appears to do what the comment says><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">so why doesn't *that* work?<br></blockquote><blockquote type="cite"><br></blockquote><br>I think that answering these questions (and fixing the problem) is a much better idea than hacking the X86 backend to handle one specific case of this.<br><br></div></blockquote><div>The problem lies in this bit of code in X86InstrInfo::AnalyzeBranch:</div><div><br></div><div>    // If they differ, see if they fit one of the known patterns. Theoretically,                                                                                         </div><div>    // we could handle more patterns here, but we shouldn't expect to see them                                                                                           </div><div>    // if instruction selection has done a reasonable job.                                                                                                               </div><div>    if ((OldBranchCode == X86::COND_NP &&</div><div>         BranchCode == X86::COND_E) ||</div><div>        (OldBranchCode == X86::COND_E &&</div><div>         BranchCode == X86::COND_NP))</div><div>      BranchCode = X86::COND_NP_OR_E;</div><div>    else if ((OldBranchCode == X86::COND_P &&</div><div>              BranchCode == X86::COND_NE) ||</div><div>             (OldBranchCode == X86::COND_NE &&</div><div>              BranchCode == X86::COND_P))</div><div>      BranchCode = X86::COND_NE_OR_P;</div><div>    else</div><div>      return true;</div><div><br></div></div>When the code in BranchFolding calls<font class="Apple-style-span" color="#540000"> "ReverseBranchCondition", the X86 back-end isn't able to handle it. So it doesn't change the branch conditions.</font><div><font class="Apple-style-span" color="#540000"><br></font></div><div><font class="Apple-style-span" color="#540000">If you look for the bits of code that handle COND_NP_OR_E and COND_NE_OR_P there doesn't seem to be any optimizations done with them. X86InstrInfo::InsertBranch looks at them and inserts two branches.</font></div><div><font class="Apple-style-span" color="#540000"><br></font></div><div><font class="Apple-style-span" color="#540000">What is the rationale behind converting a JE/JNP and JNE/JP into COND_NE_OR_P and COND_NP_OR_E?</font></div></div></blockquote><div><br></div>I think these are used to merge two conditional branches into one and split them back out again later. It seems like a hack to allow AnalyzeBranch to handle BB with two conditional branches. They correspond to OEQ and UNE.</div><div><br></div><div>Is it possible to teach <span class="Apple-style-span" style="color: rgb(84, 0, 0); ">ReverseBranchCondition to do the right thing? Ain't OEQ the reverse of UNE and vice versa?</span></div><div><font class="Apple-style-span" color="#540000"><br></font></div><div><font class="Apple-style-span" color="#540000">Evan</font></div><div><font class="Apple-style-span" color="#540000"><br></font><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><font class="Apple-style-span" color="#540000"><br></font></div><div><font class="Apple-style-span" color="#540000">-bw</font></div><div><font class="Apple-style-span" color="#540000"><br></font></div></div>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<br></blockquote></div><br></body></html>