summaryrefslogtreecommitdiffstats
path: root/llvm/test/Analysis/LoopAccessAnalysis/memcheck-for-loop-invariant.ll
Commit message (Collapse)AuthorAgeFilesLines
* [PM] Avoid getResult on a higher level in LoopAccessAnalysisSean Silva2016-07-071-1/+1
| | | | | | | Note that require<domtree> and require<loops> aren't needed because they come in implicitly via the loop pass manager. llvm-svn: 274712
* [PM] Port LoopAccessInfo analysis to new PMXinliang David Li2016-07-021-0/+1
| | | | | | | It is implemented as a LoopAnalysis pass as discussed and agreed upon. llvm-svn: 274452
* [LAA] Support memchecks involving loop-invariant addressesAdam Nemet2016-03-241-0/+38
We used to only allow SCEVAddRecExpr for pointer expressions in order to be able to compute the bounds. However this is also trivially possible for loop-invariant addresses (scUnknown) since then the bounds are the address itself. Interestingly, we used allow this for the special case when the loop-invariant address happens to also be an SCEVAddRecExpr (in an outer loop). There are a couple more loops that are vectorized in SPEC after this. My guess is that the main reason we don't see more because for example a loop-invariant load is vectorized into a splat vector with several vector-inserts. This is likely to make the vectorization unprofitable. I.e. we don't notice that a later LICM will move all of this out of the loop so the cost estimate should really be 0. llvm-svn: 264243
OpenPOWER on IntegriCloud