diff options
author | Sanjay Patel <spatel@rotateright.com> | 2020-02-24 17:05:44 -0500 |
---|---|---|
committer | Sanjay Patel <spatel@rotateright.com> | 2020-02-25 08:41:59 -0500 |
commit | 10ea01d80d6fb81d01856271dbcd6205911d451d (patch) | |
tree | 184d314adab32ad6b71f182c11632dab8ff32a5e /llvm/lib/Support/Unix | |
parent | b8d638d337e76a632d07d61f4cef59e243b961a8 (diff) | |
download | llvm-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