Commit Graph

7 Commits

Author SHA1 Message Date
Florian Hahn 555e09c2b0
[LAA] Rename printing pass to print<access-info>.
This updates the naming for the LAA printing pass to be in line with
most other analysis printing passes.

The old name has come up as confusing multiple times already, e.g. in
D131924.
2022-08-26 11:00:09 +01:00
Arthur Eubanks 34de63c37f [test] Remove unnecessary require<> in LoopAccessAnalysis tests
These function analyses are always available in loop passes.
2022-02-04 18:03:55 -08:00
Arthur Eubanks 50153213c8 [test][NewPM] Remove RUN lines using -analyze
Only tests in llvm/test/Analysis.

-analyze is legacy PM-specific.

This only touches files with `-passes`.

I looked through everything and made sure that everything had a new PM equivalent.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D109040
2021-09-02 11:38:14 -07:00
Arthur Eubanks 54e1bf1154 [LoopAccessAnalysis][NewPM] Fix tests to work under NPM
Pin RUN lines with -analyze to legacy PM, add corresponding NPM RUN lines.

Reviewed By: fhahn

Differential Revision: https://reviews.llvm.org/D87662
2020-09-15 11:06:47 -07:00
Sean Silva 284b0324e2 [PM] Avoid getResult on a higher level in LoopAccessAnalysis
Note that require<domtree> and require<loops> aren't needed because they
come in implicitly via the loop pass manager.

llvm-svn: 274712
2016-07-07 01:01:53 +00:00
Xinliang David Li 8a021317a2 [PM] Port LoopAccessInfo analysis to new PM
It is implemented as a LoopAnalysis pass as 
discussed and agreed upon.

llvm-svn: 274452
2016-07-02 21:18:40 +00:00
Adam Nemet 279784ffc4 [LAA] Support memchecks involving loop-invariant addresses
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
2016-03-24 04:28:47 +00:00