[all-commits] [llvm/llvm-project] 73cdcc: [DAG] expandIntMINMAX - attempt to match existing ...

[Simon Pilgrim via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 73cdccad55550fca4bb8b1c2d0cbe9e9218aaa6b
      https://github.com/llvm/llvm-project/commit/73cdccad55550fca4bb8b1c2d0cbe9e9218aaa6b
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2023-03-01 (Wed, 01 Mar 2023)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/test/CodeGen/X86/abds-vector-128.ll
    M llvm/test/CodeGen/X86/abdu-vector-128.ll
    M llvm/test/CodeGen/X86/midpoint-int-vec-128.ll
    M llvm/test/CodeGen/X86/vselect-minmax.ll

  Log Message:
  -----------
  [DAG] expandIntMINMAX - attempt to match existing SETCC node

As noticed on D144789, when we have pairs of min/max nodes we often end up with multiple comparisons which we could reuse with commuted select ops, so check to see if a suitable SETCC already exists. This also allowed us to remove a similar X86 peephole.

There are other getSETCC cases where we could safely reuse other CondCodes as well - I've been trying to think of how we could reuse this logic in SelectionDAG but haven't found anything that always works well.

An alternative would be to have a TLI callback that returns a preferred CondCode from a list of options, I've noticed this helped fpclamptosat tests on some other targets (MVE + WebAssembly), but other tests suffered.

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