[all-commits] [llvm/llvm-project] 0f32a5: [InstCombine] don't canonicalize shl+sub to mul+add

[Sanjay Patel via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0f32a5dea0e9ef5a52865f9fd285b394d46babaf
      https://github.com/llvm/llvm-project/commit/0f32a5dea0e9ef5a52865f9fd285b394d46babaf
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2022-09-21 (Wed, 21 Sep 2022)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineNegator.cpp
    M llvm/test/CodeGen/AMDGPU/reqd-work-group-size.ll
    M llvm/test/Transforms/InstCombine/mul-inseltpoison.ll
    M llvm/test/Transforms/InstCombine/mul.ll
    M llvm/test/Transforms/InstCombine/shl-bo.ll
    M llvm/test/Transforms/InstCombine/shl-sub.ll
    M llvm/test/Transforms/InstCombine/sub-of-negatible-inseltpoison.ll
    M llvm/test/Transforms/InstCombine/sub-of-negatible.ll
    M llvm/test/Transforms/InstCombine/sub.ll
    M llvm/test/Transforms/LoopVectorize/AArch64/sve-vector-reverse.ll

  Log Message:
  -----------
  [InstCombine] don't canonicalize shl+sub to mul+add

This stops Negator from transforming:
`C1 - shl X, C2 --> mul X, (1<<C2) + C1`
...in the general case. There does not seem to be any analysis
benefit to using mul in IR, and there's definitely downside in
codegen (particularly when the multiply has to be expanded).

If `C1` is 0, then there's a stronger argument that the single
mul is a better canonicalization than negate-of-shl, but we may
want to remove that too.

This was noted as a potential conflict for D133667.

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