[all-commits] [llvm/llvm-project] a2d68b: [SelectOpt] Add handling for Select-like operation...

[David Green via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a2d68b4bece54bcfa7bfde1e80058ab19b6d1775
      https://github.com/llvm/llvm-project/commit/a2d68b4bece54bcfa7bfde1e80058ab19b6d1775
  Author: David Green <david.green at arm.com>
  Date:   2024-01-22 (Mon, 22 Jan 2024)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetTransformInfo.h
    M llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
    M llvm/lib/Analysis/TargetTransformInfo.cpp
    M llvm/lib/CodeGen/SelectOptimize.cpp
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.h
    M llvm/test/CodeGen/AArch64/selectopt.ll

  Log Message:
  -----------
  [SelectOpt] Add handling for Select-like operations. (#77284)

Some operations behave like selects. For example `or(zext(c), y)` is the
same as select(c, y|1, y)` and instcombine can canonicalize the select
to the or form. These operations can still be worthwhile converting to
branch as opposed to keeping as a select or or instruction.

This patch attempts to add some basic handling for them, creating a
SelectLike abstraction in the select optimization pass. The backend can
opt into handling `or(zext(c),x)` as a select if it could be profitable,
and the select optimization pass attempts to handle them in much the
same way as a `select(c, x|1, x)`. The Or(x, 1) may need to be added as
a new instruction, generated as the or is converted to branches.

This helps fix a regression from selects being converted to or's
recently.