[PATCH] D42607: [LoopStrengthReduce, x86] don't add cost for a cmp that will be macro-fused (PR35681)

[Sanjay Patel via Phabricator via llvm-commits]

spatel created this revision.
spatel added reviewers: evstupac, zvi, RKSimon, hfinkel, venkataramanan.kumar.llvm, DavidKreitzer, GGanesh, craig.topper.
Herald added a subscriber: mcrosier.

I think there would be a small code size win from this change and possibly a slight perf win, but I don't have a representative benchmarking system to test that theory. I figure it's worth posting this patch to get feedback and let others give it a try if they're interested. If you have access to SPEC or other standard benchmarks, I'd be most grateful to know if it helps.

The irony is that AMD Jaguar apparently does not have macro-fusion, so the target I was hoping to help the most is excluded from consideration...

In the motivating case from PR35681 and represented in the new test in this patch:
https://bugs.llvm.org/show_bug.cgi?id=35681
...there's a 37 -> 31 byte size win for the loop because we eliminate the big base address offsets.


https://reviews.llvm.org/D42607

Files:
  include/llvm/Analysis/TargetTransformInfo.h
  include/llvm/Analysis/TargetTransformInfoImpl.h
  lib/Analysis/TargetTransformInfo.cpp
  lib/Target/X86/X86TargetTransformInfo.cpp
  lib/Target/X86/X86TargetTransformInfo.h
  lib/Transforms/Scalar/LoopStrengthReduce.cpp
  test/CodeGen/X86/rdrand.ll
  test/Transforms/LoopStrengthReduce/X86/ivchain-X86.ll
  test/Transforms/LoopStrengthReduce/X86/macro-fuse-cmp.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D42607.131663.patch
Type: text/x-patch
Size: 11275 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180126/5ce63c81/attachment.bin>