The code comments didn't match the code logic, and we didn't actually distinguish the fake unary (not/neg/fneg) operators from arguments. Adding another level to the weighting scheme provides more structure and can help simplify the pattern matching in InstCombine and other places.
I fixed regressions that would have shown up from this change in:
rL290067
rL290127
But that doesn't mean there are no pattern-matching logic holes left; some combines may just be missing regression tests.
The cmp predicate changes in the LoopVectorize/minmax_reduction.ll test show a potential missed canonicalization for min/max ops.
Should fix:
https://llvm.org/bugs/show_bug.cgi?id=28296
UnaryInstruction includes a lot of instructions, many of which are not really obvious; please enumerate the specific instructions you care about.
An explanation for why we want to use this ordering, as opposed to RPO order or something like that, would also be nice.