[SCEV] Compute affine range in another way to avoid bitwidth extending.

Authored by mzolotukhin on Mar 16 2017, 2:07 PM.


[SCEV] Compute affine range in another way to avoid bitwidth extending.

This approach has two major advantages over the existing one:

  1. We don't need to extend bitwidth in our computations. Extending

bitwidth is a big issue for compile time as we often end up working with
APInts wider than 64bit, which is a slow case for APInt.

  1. When we zero extend a wrapped range, we lose some information (we

replace the range with [0, 1 << src bit width)). Thus, avoiding such
extensions better preserves information.

Correctness testing:
I ran 'ninja check' with assertions that the new implementation of
getRangeForAffineAR gives the same results as the old one (this
functionality is not present in this patch). There were several failures

  • I inspected them manually and found out that they all are caused by

the fact that we're returning more accurate results now (see bullet (2)
Without such assertions 'ninja check' works just fine, as well as

Compile time testing:

  • mafft/pairlocalalign -16.98%
  • tramp3d-v4/tramp3d-v4 -12.72%
  • lencod/lencod -11.51%
  • Bullet/bullet -4.36%
  • ClamAV/clamscan -3.66%
  • 7zip/7zip-benchmark -3.19%
  • sqlite3/sqlite3 -2.95%
  • SPASS/SPASS -2.74%
  • Average -5.81%

Performance testing:
The changes are expected to be neutral for runtime performance.

Reviewers: sanjoy, atrick, pete

Subscribers: llvm-commits

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

llvm-svn: 297992