[all-commits] [llvm/llvm-project] 5625e6: [X86] Improve min/max reduction costs.

[topperc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 5625e6ab3788a788662f48dc7f5119defb43f08d
      https://github.com/llvm/llvm-project/commit/5625e6ab3788a788662f48dc7f5119defb43f08d
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2020-04-09 (Thu, 09 Apr 2020)

  Changed paths:
    M llvm/lib/Target/X86/X86TargetTransformInfo.cpp
    M llvm/lib/Target/X86/X86TargetTransformInfo.h
    M llvm/test/Analysis/CostModel/X86/reduce-fmax.ll
    M llvm/test/Analysis/CostModel/X86/reduce-fmin.ll
    M llvm/test/Analysis/CostModel/X86/reduce-smax.ll
    M llvm/test/Analysis/CostModel/X86/reduce-smin.ll
    M llvm/test/Analysis/CostModel/X86/reduce-umax.ll
    M llvm/test/Analysis/CostModel/X86/reduce-umin.ll
    M llvm/test/Transforms/SLPVectorizer/X86/horizontal-minmax.ll
    M llvm/test/Transforms/SLPVectorizer/X86/vectorize-reorder-reuse.ll

  Log Message:
  -----------
  [X86] Improve min/max reduction costs.

This is similar to what I recently did for getArithmeticReductionCost.

I'm trying to account for the narrowing from 512->256->128 as we go.

I've also added a new helper method getMinMaxCost that tries to
handle the cases where we have native min/max instructions and
fall back to cmp+select when we don't.

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