|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| ... |  | 
| | 
| 
| 
| 
| 
| 
| | ICmpInst::makeConstantRange does exactly the same thing as
ConstantRange::makeExactICmpRegion.
llvm-svn: 283059 | 
| | 
| 
| 
| | llvm-svn: 283058 | 
| | 
| 
| 
| | llvm-svn: 283056 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Instead of creating and destroying SCEVUnionPredicate instances (which
internally creates and destroys a DenseMap), use temporary SmallPtrSet
instances of remember the set of predicates that will get reified into a
SCEVUnionPredicate.
Reviewers: silviu.baranga, sbaranga
Subscribers: sanjoy, mcrosier, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D25000
llvm-svn: 282606 | 
| | 
| 
| 
| 
| 
| | We can do this now thanks to C++11 lambdas.
llvm-svn: 282515 | 
| | 
| 
| 
| 
| 
| | We don't need the extra generality here.
llvm-svn: 282514 | 
| | 
| 
| 
| | llvm-svn: 282513 | 
| | 
| 
| 
| 
| 
| | Instead use the pre-existing `scope_exit` class.
llvm-svn: 282512 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | I don't expect `PendingLoopPredicates` to have very many
elements (e.g. when -O3'ing the sqlite3 amalgamation,
`PendingLoopPredicates` has at most 3 elements).  So now we use a
`SmallPtrSet` for it instead of the more heavyweight `DenseSet`.
llvm-svn: 282511 | 
| | 
| 
| 
| 
| 
| 
| | Noticed due to the warning on this line. Sanjoy is on
a less-than-awesome internet connection, so committing on his behalf.
llvm-svn: 282380 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | In a previous change I collapsed two different caches into one.  When
doing that I noticed that ScalarEvolution's move constructor was not
moving those caches.
To keep the previous change simple, I've moved that bugfix into this
separate change.
llvm-svn: 282376 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | Both `loopHasNoSideEffects` and `loopHasNoAbnormalExits` involve walking
the loop and maintaining similar sorts of caches.  This commit changes
SCEV to compute both the predicates via a single walk, and maintain a
single cache instead of two.
llvm-svn: 282375 | 
| | 
| 
| 
| 
| 
| 
| | Specifically, it moves SCEVUnionPredicates from its input into its own
storage.  Make this obvious at the type level.
llvm-svn: 282374 | 
| | 
| 
| 
| | llvm-svn: 282373 | 
| | 
| 
| 
| | llvm-svn: 282372 | 
| | 
| 
| 
| | llvm-svn: 282368 | 
| | 
| 
| 
| 
| 
| 
| | SCEVUnionPredicate is a "heavyweight" structure, so it is beneficial to
store the (optional) data out of line.
llvm-svn: 282366 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This change simplifies a data structure optimization in the
`BackedgeTakenInfo` class for loops with exactly one computable exit.
I've sanity checked that this does not regress compile time performance,
using sqlite3's amalgamated build.
llvm-svn: 282365 | 
| | 
| 
| 
| | llvm-svn: 282364 | 
| | 
| 
| 
| | llvm-svn: 282363 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | Enhance SCEV to compute the trip count for some loops with unknown stride.
Patch by Pankaj Chawla
Differential Revision: https://reviews.llvm.org/D22377
llvm-svn: 281732 | 
| | 
| 
| 
| 
| 
| 
| 
| | (PR28932)
Differential Revision: https://reviews.llvm.org/D23594
llvm-svn: 278999 | 
| | 
| 
| 
| 
| 
| | Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970 | 
| | 
| 
| 
| 
| 
| 
| 
| | stride."
This reverts commit r278731. It caused http://crbug.com/638314
llvm-svn: 278853 | 
| | 
| 
| 
| 
| 
| 
| 
| | Patch by Pankaj Chawla
Differential Revision: https://reviews.llvm.org/D22377
llvm-svn: 278731 | 
| | 
| 
| 
| 
| 
| | No functionality change is intended.
llvm-svn: 278475 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
  S1 = S2 + C_a
  S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Besides a general consistently benefit, the extra layer of indirection
allows the mechanical part of https://reviews.llvm.org/D23256 that
requires touching every transformation and analysis to be factored out
cleanly.
Thanks to David for the suggestion.
llvm-svn: 278077 | 
| | 
| 
| 
| | llvm-svn: 277848 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | expansion."
It causes Clang tests to fail after Windows self-host (PR28705).
(Also reverts follow-up r276139.)
llvm-svn: 276822 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This change lets us prove things like
  "{X,+,10} s< 5000" implies "{X+7,+,10} does not sign overflow"
It does this by replacing replacing getConstantDifference by
computeConstantDifference (which is smarter) in
isImpliedCondOperandsViaRanges.
llvm-svn: 276505 | 
| | 
| 
| 
| 
| 
| 
| | This is in preparation of
s/getConstantDifference/computeConstantDifference/ in a later change.
llvm-svn: 276503 | 
| | 
| 
| 
| 
| 
| 
| | The helper will get smarter in a later change, but right now this is
just code reorganization.
llvm-svn: 276467 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
  S1 = S2 + C_a
  S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 276136 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | When building SCEVs, if a function is known to return its argument, then we can
build the SCEV using the corresponding argument value.
Differential Revision: http://reviews.llvm.org/D9381
llvm-svn: 275037 | 
| | 
| 
| 
| | llvm-svn: 274479 | 
| | 
| 
| 
| 
| 
| 
| 
| | where possible.
No functionality change intended.
llvm-svn: 274431 | 
| | 
| 
| 
| 
| 
| 
| | In particular, check to see if we can compute a precise trip count by
exhaustively simulating the loop first.
llvm-svn: 274199 | 
| | 
| 
| 
| 
| 
| | Only minor manual fixes. No functionality change intended.
llvm-svn: 273816 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The way we elide max expressions when computing trip counts is incorrect
-- it breaks cases like this:
```
static int wrapping_add(int a, int b) {
  return (int)((unsigned)a + (unsigned)b);
}
void test() {
  volatile int end_buf = 2147483548; // INT_MIN - 100
  int end = end_buf;
  unsigned counter = 0;
  for (int start = wrapping_add(end,  200); start < end; start++)
    counter++;
  print(counter);
}
```
Note: the `NoWrap` variable that was being tested has little to do with
the values flowing into the max expression; it is a property of the
induction variable.
test/Transforms/LoopUnroll/nsw-tripcount.ll was added to solely test
functionality I'm reverting in this change, so I've deleted the test
fully.
llvm-svn: 273079 | 
| | 
| 
| 
| 
| 
| | The const is unnecessary.
llvm-svn: 272759 | 
| | 
| 
| 
| | llvm-svn: 272758 | 
| | 
| 
| 
| | llvm-svn: 272753 | 
| | 
| 
| 
| 
| 
| 
| 
| | Use Optional<T> to denote the absence of a solution, not
SCEVCouldNotCompute.  This makes the usage of SolveQuadraticEquation
somewhat simpler.
llvm-svn: 272752 | 
| | 
| 
| 
| | llvm-svn: 272238 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | We can safely rely on a NoWrap add recurrence causing UB down the road
only if we know the loop does not have a exit expressed in a way that is
opaque to ScalarEvolution (e.g. by a function call that conditionally
calls exit(0)).
I believe with this change PR28012 is fixed.
Note: I had to change some llvm-lit tests in LoopReroll, since it looks
like they were depending on this incorrect behavior.
llvm-svn: 272237 | 
| | 
| 
| 
| | llvm-svn: 272236 | 
| | 
| 
| 
| 
| 
| 
| | Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.
llvm-svn: 272190 | 
| | 
| 
| 
| 
| 
| 
| | This is NFC as far as externally visible behavior is concerned, but will
keep us from spinning in the worklist traversal algorithm unnecessarily.
llvm-svn: 272182 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Absence of may-unwind calls is not enough to guarantee that a
UB-generating use of an add-rec poison in the loop latch will actually
cause UB.  We also need to guard against calls that terminate the thread
or infinite loop themselves.
This partially addresses PR28012.
llvm-svn: 272181 |