aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/Unix
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2020-02-24 17:05:44 -0500
committerSanjay Patel <spatel@rotateright.com>2020-02-25 08:41:59 -0500
commit10ea01d80d6fb81d01856271dbcd6205911d451d (patch)
tree184d314adab32ad6b71f182c11632dab8ff32a5e /llvm/lib/Support/Unix
parentb8d638d337e76a632d07d61f4cef59e243b961a8 (diff)
downloadllvm-10ea01d80d6fb81d01856271dbcd6205911d451d.zip
llvm-10ea01d80d6fb81d01856271dbcd6205911d451d.tar.gz
llvm-10ea01d80d6fb81d01856271dbcd6205911d451d.tar.bz2
[VectorCombine] make cost calc consistent for binops and cmps
Code duplication (subsequently removed by refactoring) allowed a logic discrepancy to creep in here. We were being conservative about creating a vector binop -- but not a vector cmp -- in the case where a vector op has the same estimated cost as the scalar op. We want to be more aggressive here because that can allow other combines based on reduced instruction count/uses. We can reverse the transform in DAGCombiner (potentially with a more accurate cost model) if this causes regressions. AFAIK, this does not conflict with InstCombine. We have a scalarize transform there, but it relies on finding a constant operand or a matching insertelement, so that means it eliminates an extractelement from the sequence (so we won't have 2 extracts by the time we get here if InstCombine succeeds). Differential Revision: https://reviews.llvm.org/D75062
Diffstat (limited to 'llvm/lib/Support/Unix')
0 files changed, 0 insertions, 0 deletions