[all-commits] [llvm/llvm-project] 21d7c3: [DAG] try to convert multiply to shift via demande...

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 21d7c3bcc646f5db73bc3d21f9d1b1327b6a5ec0
      https://github.com/llvm/llvm-project/commit/21d7c3bcc646f5db73bc3d21f9d1b1327b6a5ec0
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-02-23 (Wed, 23 Feb 2022)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
    M llvm/test/CodeGen/AArch64/mul_pow2.ll
    M llvm/test/CodeGen/Mips/urem-seteq-illegal-types.ll
    M llvm/test/CodeGen/RISCV/mul.ll
    M llvm/test/CodeGen/X86/mul-demand.ll

  Log Message:
  -----------
  [DAG] try to convert multiply to shift via demanded bits

This is a fix for a regression discussed in:
https://github.com/llvm/llvm-project/issues/53829

We cleared more high multiplier bits with 995d400,
but that can lead to worse codegen because we would fail
to recognize the now disguised multiplication by neg-power-of-2
as a shift-left. The problem exists independently of the IR
change in the case that the multiply already had cleared high
bits. We also convert shl+sub into mul+add in instcombine's
negator.

This patch fills in the high-bits to see the shift transform
opportunity. Alive2 attempt to show correctness:
https://alive2.llvm.org/ce/z/GgSKVX

The AArch64, RISCV, and MIPS diffs look like clear wins. The
x86 code requires an extra move register in the minimal examples,
but it's still an improvement to get rid of the multiply on all
CPUs that I am aware of (because multiply is never as fast as a
shift).

There's a potential follow-up noted by the TODO comment. We
should already convert that pattern into shl+add in IR, so
it's probably not common:
https://alive2.llvm.org/ce/z/7QY_Ga

Fixes #53829

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