OSDN Git Service

[SCEV] Compute affine range in another way to avoid bitwidth extending.
authorMichael Zolotukhin <mzolotukhin@apple.com>
Thu, 16 Mar 2017 21:07:38 +0000 (21:07 +0000)
committerMichael Zolotukhin <mzolotukhin@apple.com>
Thu, 16 Mar 2017 21:07:38 +0000 (21:07 +0000)
commit78dce2577dfbc9d790a310b4d7e24b195a44a552
tree35952e8a12cfba3209e848e2269776fa555b6406
parentd289ddded8f19534d8caff9e979ed03e6fdb1e93
[SCEV] Compute affine range in another way to avoid bitwidth extending.

Summary:
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.
2. 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)
above).
Without such assertions 'ninja check' works just fine, as well as
SPEC2006.

Compile time testing:
CTMark/Os:
 - 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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@297992 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Analysis/ScalarEvolution.cpp
test/Analysis/ScalarEvolution/zext-wrap.ll