author | Chandler Carruth <chandlerc@gmail.com> | |
Tue, 25 Feb 2014 21:54:50 +0000 (21:54 +0000) | ||
committer | Chandler Carruth <chandlerc@gmail.com> | |
Tue, 25 Feb 2014 21:54:50 +0000 (21:54 +0000) | ||
commit | 9c256eccb355fb26072ad5353a2f886f62118aa8 | |
tree | f5ef399f578d4808c781c47ad77b83654a06dd7b | tree | snapshot (tar.xz tar.gz zip) |
parent | 431e9f03106ad217af461780836cd7f4bb075a5d | commit | diff |
[reassociate] Switch two std::sort calls into std::stable_sort calls as
their inputs come from std::stable_sort and they are not total orders.
I'm not a huge fan of this, but the really bad std::stable_sort is right
at the beginning of Reassociate. After we commit to stable-sort based
consistent respect of source order, the downstream sorts shouldn't undo
that unless they have a total order or they are used in an
order-insensitive way. Neither appears to be true for these cases.
I don't have particularly good test cases, but this jumped out by
inspection when looking for output instability in this pass due to
changes in the ordering of std::sort.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202196 91177308-0d34-0410-b5e6-96231b3b80d8
their inputs come from std::stable_sort and they are not total orders.
I'm not a huge fan of this, but the really bad std::stable_sort is right
at the beginning of Reassociate. After we commit to stable-sort based
consistent respect of source order, the downstream sorts shouldn't undo
that unless they have a total order or they are used in an
order-insensitive way. Neither appears to be true for these cases.
I don't have particularly good test cases, but this jumped out by
inspection when looking for output instability in this pass due to
changes in the ordering of std::sort.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202196 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Scalar/Reassociate.cpp | diff | blob | history |