maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

Remove the "special tie breaker" because it resulted in inconsistent 

ordering and thus violated the strict weak ordering requirement of
priority_queue.  Uncovered by _GLIBCXX_DEBUG.

llvm-svn: 37794
This commit is contained in:
David Greene 2007-06-29 02:48:09 +00:00
parent 451d1a6ecd
commit 5b6f755575
1 changed files with 12 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
llvm/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
View File

@ -618,16 +618,18 @@ bool bu_ls_rr_sort::operator()(const SUnit *left, const SUnit *right) const {
bool LIsTarget = left->Node->isTargetOpcode();
bool RIsTarget = right->Node->isTargetOpcode();
// Special tie breaker: if two nodes share a operand, the one that use it
// as a def&use operand is preferred.
if (LIsTarget && RIsTarget) {
if (left->isTwoAddress && !right->isTwoAddress)
if (SPQ->isDUOperand(left, right))
return false;
if (!left->isTwoAddress && right->isTwoAddress)
if (SPQ->isDUOperand(right, left))
return true;
}
// Cray: There used to be a special tie breaker here that looked for
// two-address instructions and preferred the instruction with a
// def&use operand. The special case triggered diagnostics when
// _GLIBCXX_DEBUG was enabled because it broke the strict weak
// ordering that priority_queue requires. It didn't help much anyway
// because AddPseudoTwoAddrDeps already covers many of the cases
// where it would have applied. In addition, it's counter-intuitive
// that a tie breaker would be the first thing attempted. There's a
// "real" tie breaker below that is the operation of last resort.
// The fact that the "special tie breaker" would trigger when there
// wasn't otherwise a tie is what broke the strict weak ordering
// constraint.
unsigned LPriority = SPQ->getNodePriority(left);
unsigned RPriority = SPQ->getNodePriority(right);