[all-commits] [llvm/llvm-project] 15e3d8: [InstCombine] reassociate bitwise logic chains bas...

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 15e3d869119289991072679f82622072818468e6
      https://github.com/llvm/llvm-project/commit/15e3d869119289991072679f82622072818468e6
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-08-21 (Sun, 21 Aug 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
    M llvm/test/Transforms/InstCombine/and-or-icmps.ll
    M llvm/test/Transforms/InstCombine/and-or-not.ll
    M llvm/test/Transforms/InstCombine/and-or.ll
    M llvm/test/Transforms/InstCombine/and-xor-or.ll
    M llvm/test/Transforms/LoopVectorize/ARM/mve-reduction-predselect.ll
    M llvm/test/Transforms/LoopVectorize/reduction-predselect.ll

  Log Message:
  -----------
  [InstCombine] reassociate bitwise logic chains based on uses

(X op Y) op Z --> (Y op Z) op X

This isn't a complete solution (see TODO tests for possible refinements),
but it shows some nice wins and doesn't seem to cause any harm. I think
the most potential danger is from conflicting with other folds and causing
an infinite loop - that's the reason for avoiding patterns with constant
operands.

Alternatively, we could try this in the reassociate pass, but we would not
immediately see all of the logic folds that instcombine provides. I also
looked at improving ValueTracking's isImpliedCondition() (and we should
still add some enhancements there), but that would not work in general for
bitwise logic reduction.

The tests that reduce completely to 0/-1 are motivated by issue #56653.

Differential Revision: https://reviews.llvm.org/D131356