Commit Graph

70 Commits

Author SHA1 Message Date
Adam Nemet
f959df643a [LAA] Fix line break in comment
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241785 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-09 06:47:21 +00:00
Adam Nemet
ecb6a37111 [LAA] Rename IsRTNeeded to IsRTCheckAnalysisNeeded
The original name was too close to NeedRTCheck which is what the actual
memcheck analysis returns.  This flag, as the new name suggests, is only
used to whether to initiate that analysis.

Also a comment is added to answer one question I had about this code for
a long time.  Namely, how does this flag differ from
isDependencyCheckNeeded since they are seemingly set at the same time.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241784 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-09 06:47:18 +00:00
Adam Nemet
f7f4697e3c [LAA] Fix misleading use of word 'consecutive'
Fix some places where the word consecutive is used but the code really
means constant-stride (i.e. not just unit stride).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241763 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-09 00:03:22 +00:00
Adam Nemet
7a6f54545f [LAA] Revert a small part of r239295
This commit ([LAA] Fix estimation of number of memchecks) regressed the
logic a bit.  We shouldn't quit the analysis if we encounter a pointer
without known bounds *unless* we actually need to emit a memcheck for
it.

The original code was using NumComparisons which is now computed
differently.  Instead I compute NeedRTCheck from NumReadPtrChecks and
NumWritePtrChecks.

As side note, I find the separation of NeedRTCheck and CanDoRT
confusing, so I will try to merge them in a follow-up patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241756 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-08 22:58:48 +00:00
Adam Nemet
b089d62c9a [LAA] Add missing debug output after r239285
r239285 ([LoopAccessAnalysis] Teach LAA to check the memory dependence
between strided accesses.) introduced a new case under
MemoryDepChecker::isDependent.  We normally have debug output for each
case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241707 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-08 18:47:38 +00:00
Silviu Baranga
8bde857088 [LAA] Merge memchecks for accesses separated by a constant offset
Summary:
Often filter-like loops will do memory accesses that are
separated by constant offsets. In these cases it is
common that we will exceed the threshold for the
allowable number of checks.

However, it should be possible to merge such checks,
sice a check of any interval againt two other intervals separated
by a constant offset (a,b), (a+c, b+c) will be equivalent with
a check againt (a, b+c), as long as (a,b) and (a+c, b+c) overlap.
Assuming the loop will be executed for a sufficient number of
iterations, this will be true. If not true, checking against
(a, b+c) is still safe (although not equivalent).

As long as there are no dependencies between two accesses,
we can merge their checks into a single one. We use this
technique to construct groups of accesses, and then check
the intervals associated with the groups instead of
checking the accesses directly.

Reviewers: anemet

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10386

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241673 91177308-0d34-0410-b5e6-96231b3b80d8
2015-07-08 09:16:33 +00:00
David Blaikie
26bc54301b Move VectorUtils from Transforms to Analysis to correct layering violation
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240804 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-26 18:02:52 +00:00
Adam Nemet
e11d1d2c31 [LAA] Try to prove non-wrapping of pointers if SCEV cannot
Summary:
Scalar evolution does not propagate the non-wrapping flags to values
that are derived from a non-wrapping induction variable because
the non-wrapping property could be flow-sensitive.

This change is a first attempt to establish the non-wrapping property in
some simple cases.  The main idea is to look through the operations
defining the pointer.  As long as we arrive to a non-wrapping AddRec via
a small chain of non-wrapping instruction, the pointer should not wrap
either.

I believe that this essentially is what Andy described in
http://article.gmane.org/gmane.comp.compilers.llvm.cvs/220731 as the way
forward.

Reviewers: aschwaighofer, nadav, sanjoy, atrick

Reviewed By: atrick

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10472

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240798 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-26 17:25:43 +00:00
Chandler Carruth
2cdca0c4e4 [PM/AA] Remove the UnknownSize static member from AliasAnalysis.
This is now living in MemoryLocation, which is what it pertains to. It
is also an enum there rather than a static data member which is left
never defined.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239886 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-17 07:21:38 +00:00
Chandler Carruth
4d7ed3960c [PM/AA] Remove the Location typedef from the AliasAnalysis class now
that it is its own entity in the form of MemoryLocation, and update all
the callers.

This is an entirely mechanical change. References to "Location" within
AA subclases become "MemoryLocation", and elsewhere
"AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps
out-of-tree folks update.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239885 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-17 07:18:54 +00:00
Silviu Baranga
a420a14276 [LAA] Fix estimation of number of memchecks
Summary:
We need to add a runtime memcheck for pair of accesses (x,y) where at least one of x and y
are writes.
 
Assuming we have w writes and r reads, currently this number is  estimated as being
w* (w+r-1). This estimation will count (write,write) pairs twice and will overestimate
the number of checks required.

This change adds a getNumberOfChecks method to RuntimePointerCheck, which
will count the number of runtime checks needed (similar in implementation to
needsAnyChecking) and uses it to produce the correct number of runtime checks.

Test Plan:
llvm test suite
spec2k
spec2k6

Performance results: no changes observed (not surprising since the formula for 1 writer is basically the same, which would covers most cases - at least with the current check limit).

Reviewers: anemet

Reviewed By: anemet

Subscribers: mzolotukhin, llvm-commits

Differential Revision: http://reviews.llvm.org/D10217

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239295 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-08 10:27:06 +00:00
Hao Liu
43be1d53d1 [LoopVectorize] Teach Loop Vectorizor about interleaved memory accesses.
Interleaved memory accesses are grouped and vectorized into vector load/store and shufflevector.
E.g. for (i = 0; i < N; i+=2) {
       a = A[i];         // load of even element
       b = A[i+1];       // load of odd element
       ...               // operations on a, b, c, d
       A[i] = c;         // store of even element
       A[i+1] = d;       // store of odd element
     }

  The loads of even and odd elements are identified as an interleave load group, which will be transfered into vectorized IRs like:
     %wide.vec = load <8 x i32>, <8 x i32>* %ptr
     %vec.even = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
     %vec.odd = shufflevector <8 x i32> %wide.vec, <8 x i32> undef, <4 x i32> <i32 1, i32 3, i32 5, i32 7>

  The stores of even and odd elements are identified as an interleave store group, which will be transfered into vectorized IRs like:
     %interleaved.vec = shufflevector <4 x i32> %vec.even, %vec.odd, <8 x i32> <i32 0, i32 4, i32 1, i32 5, i32 2, i32 6, i32 3, i32 7> 
     store <8 x i32> %interleaved.vec, <8 x i32>* %ptr

This optimization is currently disabled by defaut. To try it by adding '-enable-interleaved-mem-accesses=true'. 



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239291 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-08 06:39:56 +00:00
Hao Liu
f60ff6bdf6 [LoopAccessAnalysis] Teach LAA to check the memory dependence between strided accesses.
Differential Revision: http://reviews.llvm.org/D9368


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239285 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-08 04:48:37 +00:00
Chandler Carruth
dc967a97df [PM/AA] Start refactoring AliasAnalysis to remove the analysis group and
port it to the new pass manager.

All this does is extract the inner "location" class used by AA into its
own full fledged type. This seems *much* cleaner as MemoryDependence and
soon MemorySSA also use this heavily, and it doesn't make much sense
being inside the AA infrastructure.

This will also make it much easier to break apart the AA infrastructure
into something that stands on its own rather than using the analysis
group design.

There are a few places where this makes APIs not make sense -- they were
taking an AliasAnalysis pointer just to build locations. I'll try to
clean those up in follow-up commits.

Differential Revision: http://reviews.llvm.org/D10228

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@239003 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-04 02:03:15 +00:00
Adam Nemet
a4c8c9292b [LoopAccesses] If shouldRetryWithRuntimeCheck, reset InterestingDependences
When dependence analysis encounters a non-constant distance between
memory accesses it aborts the analysis and falls back to run-time checks
only.  In this case we weren't resetting the array of dependences.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237574 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 15:37:03 +00:00
Adam Nemet
2f2bbe4ced [LoopAccesses] Rearrange printed lines in -analyze
"Store to invariant address..." is moved as the last line.  This is not
the prime result of the analysis.  Plus it simplifies some of the tests.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237573 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 15:36:57 +00:00
Adam Nemet
59f6c04f94 [LoopAccesses] Debug improvement
Report pointers with unknown bounds.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237572 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-18 15:36:52 +00:00
Adam Nemet
50b9e7f7d4 [getUnderlyingOjbects] Analyze loop PHIs further to remove false positives
Specifically, if a pointer accesses different underlying objects in each
iteration, don't look through the phi node defining the pointer.

The motivating case is the underlyling-objects-2.ll testcase.  Consider
the loop nest:

  int **A;
  for (i)
    for (j)
       A[i][j] = A[i-1][j] * B[j]

This loop is transformed by Load-PRE to stash away A[i] for the next
iteration of the outer loop:

  Curr = A[0];          // Prev_0
  for (i: 1..N) {
    Prev = Curr;        // Prev = PHI (Prev_0, Curr)
    Curr = A[i];
    for (j: 0..N)
       Curr[j] = Prev[j] * B[j]
  }

Since A[i] and A[i-1] are likely to be independent pointers,
getUnderlyingObjects should not assume that Curr and Prev share the same
underlying object in the inner loop.

If it did we would try to dependence-analyze Curr and Prev and the
analysis of the corresponding SCEVs would fail with non-constant
distance.

To fix this, the getUnderlyingObjects API is extended with an optional
LoopInfo parameter.  This is effectively what controls whether we want
the above behavior or the original.  Currently, I only changed to use
this approach for LoopAccessAnalysis.

The other testcase is to guard the opposite case where we do want to
look through the loop PHI.  If we step through an array by incrementing
a pointer, the underlying object is the incoming value of the phi as the
loop is entered.

Fixes rdar://problem/19566729

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235634 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-23 20:09:20 +00:00
Adam Nemet
ee5f9c6278 [LoopAccesses] Improve debug output
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235238 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 22:43:10 +00:00
Adam Nemet
1624f35f2b [LoopAccesses] Properly print whether memchecks are needed
Fix oversight in -analyze output.  PtrRtCheck contains the pointers that
need to be checked against each other and not whether memchecks are
necessary.

For instance in the testcase PtrRtCheck has four elements but all
no-alias so no checking is necessary.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234833 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 01:12:55 +00:00
Adam Nemet
cd13a3808a [LoopAccesses] Allow analysis to complete in the presence of uniform stores
(Re-apply r234361 with a fix and a testcase for PR23157)

Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.

Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).

In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.

When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).

The changes also adds support to query this property of the loop and
modify the vectorizer to use this.

Patch by Ashutosh Nema!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234424 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-08 17:48:40 +00:00
Adam Nemet
b343d1cd85 Revert "[LoopAccesses] Allow analysis to complete in the presence of uniform stores"
This reverts commit r234361.

It caused PR23157.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234387 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-08 04:16:55 +00:00
Adam Nemet
a0834f1d87 [LoopAccesses] Allow analysis to complete in the presence of uniform stores
Both run-time pointer checking and the dependence analysis are capable
of dealing with uniform addresses. I.e. it's really just an orthogonal
property of the loop that the analysis computes.

Run-time pointer checking will only try to reason about SCEVAddRec
pointers or else gives up. If the uniform pointer turns out the be a
SCEVAddRec in an outer loop, the run-time checks generated will be
correct (start and end bounds would be equal).

In case of the dependence analysis, we work again with SCEVs. When
compared against a loop-dependent address of the same underlying object,
the difference of the two SCEVs won't be constant. This will result in
returning an Unknown dependence for the pair.

When compared against another uniform access, the difference would be
constant and we should return the right type of dependence
(forward/backward/etc).

The changes also adds support to query this property of the loop and
modify the vectorizer to use this.

Patch by Ashutosh Nema!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234361 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-07 21:46:16 +00:00
Adam Nemet
ad8a6b66d9 [LoopAccesses] New API to query if memchecks are necessary after partitioning
This is used by Loop Distribution.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234283 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-07 03:35:26 +00:00
Adam Nemet
e1aa33fb9a [LoopAccesses] Handle case when no memchecks are needed after partitioning
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233930 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-02 17:51:57 +00:00
Benjamin Kramer
1bfcd1f675 Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232998 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-23 19:32:43 +00:00
Michael Zolotukhin
0f311db8aa LoopVectorize: teach loop vectorizer to vectorize calls.
The tests would be committed in a commit for http://reviews.llvm.org/D8131

Review: http://reviews.llvm.org/D8095

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232530 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-17 19:46:50 +00:00
Adam Nemet
31f1cc5790 [LoopAccesses] Add debug message to indicate the result of the analysis
The debug message was pretty confusing here.  It only reported the
situation with memchecks without the result of the dependence analysis.

Now it prints whether the loop is safe from the POV of the dependence
analysis and if yes, whether we need memchecks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231854 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 21:47:39 +00:00
David Majnemer
3e616ba7b9 LoopAccessAnalysis: Silence -Wreturn-type diagnostic from GCC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231836 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 20:23:29 +00:00
Adam Nemet
73dff35fac [LAA-memchecks] Comment improvement
I forgot to roll this into r231816.  It was requested by Hal in D8122.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231821 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 19:12:41 +00:00
Adam Nemet
86dbc2b6d3 [LAA-memchecks 3/3] Introduce pointer partitions for memchecks
This is the final patch that actually introduces the new parameter of
partition mapping to RuntimePointerCheck::needsChecking.

Another API (LAI::getInstructionsForAccess) is also exposed that helps
to map pointers to instructions because ultimately we partition
instructions.

The WIP version of the Loop Distribution pass in D6930 has been adapted
to use all this.  See for example, how
InstrPartitionContainer::computePartitionSetForPointers sets up the
partitions using the above API and then calls to LAI::addRuntimeCheck
with the pointer partitions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231818 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 18:54:26 +00:00
Adam Nemet
c320ed14d2 [LAA-memchecks 2/3] Move number of memcheck threshold checking to LV
Now the analysis won't "fail" if the memchecks exceed the threshold.  It
is the transform pass' responsibility to perform the check.

This allows the transform pass to further analyze/eliminate the
memchecks.  E.g. in Loop distribution we only need to check pointers
that end up in different partitions.

Note that there is a slight change of functionality here.  The logic in
analyzeLoop is that if dependence checking fails due to non-constant
distance between the pointers, another attempt is made to prove safety
of the dependences purely using run-time checks.

Before this patch we could fail the loop due to exceeding the memcheck
threshold after the first step, now we only check the threshold in the
client after the full analysis.  There is no measurable compile-time
effect but I wanted to record this here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231817 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 18:54:23 +00:00
Adam Nemet
17c9aca856 [LAA-memchecks 1/3] Split out NumComparisons checks. NFC
The check for the number of memchecks will be moved to the client of
this analysis.  Besides allowing for transform-specific thresholds, this
also lets Loop Distribution post-process the memchecks; Loop
Distribution only needs memchecks between pointers of different
partitions.

The motivation for this first patch is to untangle the CanDoRT check
from the NumComparison check before moving the NumComparison part.
CanDoRT means that we couldn't determine the bounds for the pointer.
Note that NumComparison is set independent of this flag.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231816 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 18:54:19 +00:00
Adam Nemet
8e7d56f6f7 [LoopAccesses 3/3] Print the dependences with -analyze
The dependences are now expose through the new getInterestingDependences
API so we can use that with -analyze too and fix the FIXME.

This lets us remove the test that relied on -debug to check the
dependences.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231807 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 17:40:43 +00:00
Adam Nemet
7063c7e084 [LoopAccesses 2/3] Allow querying of interesting dependences
Gather an array of interesting dependences rather than just failing
after the first unsafe one and regarding the loop unsafe.  Loop
Distribution needs to be able to collect all dependences in order to
isolate the dependence cycles into their own partition.

Since the dependence checking algorithm is quadratic in terms of
accesses sharing the same underlying pointer, I am applying a cut-off
threshold (MaxInterestingDependence).  Exceeding that, the logic reverts
back to the original approach deeming the loop unsafe upon encountering
the first unsafe dependence.

The main idea of the patch is to split isDepedent from directly
answering the question whether the dep is safe for vectorization to
return a dependence type which then gets mapped to old boolean result
using Dependence::isSafeForVectorization.

Tested that this was compile-time neutral on SpecINT2006 LTO bitcode
inputs.  No assembly change on the testsuite including external.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231806 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 17:40:37 +00:00
Adam Nemet
0ddb48c2f8 [LoopAccesses 1/3] Expose MemoryDepChecker to LAA users
LoopDistribution needs to query various results of the dependence
analysis.  This series will expose some more APIs and state of the
dependence checker.

This patch is a simple one to just expose the DepChecker instance.  The
set is compile-time neutral measured with LTO bitcode files of
SpecINT2006.  Also there is no assembly change on the testsuite.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231805 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 17:40:34 +00:00
Mehdi Amini
529919ff31 DataLayout is mandatory, update the API to reflect it with references.
Summary:
Now that the DataLayout is a mandatory part of the module, let's start
cleaning the codebase. This patch is a first attempt at doing that.

This patch is not exactly NFC as for instance some places were passing
a nullptr instead of the DataLayout, possibly just because there was a
default value on the DataLayout argument to many functions in the API.
Even though it is not purely NFC, there is no change in the
validation.

I turned as many pointer to DataLayout to references, this helped
figuring out all the places where a nullptr could come up.

I had initially a local version of this patch broken into over 30
independant, commits but some later commit were cleaning the API and
touching part of the code modified in the previous commits, so it
seemed cleaner without the intermediate state.

Test Plan:

Reviewers: echristo

Subscribers: llvm-commits

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231740 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-10 02:37:25 +00:00
Mehdi Amini
c94da20917 Make DataLayout Non-Optional in the Module
Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

Differential Revision: http://reviews.llvm.org/D7992

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231270 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-04 18:43:29 +00:00
Adam Nemet
e382bb9e35 [LV/LoopAccesses] Backward dependences are not safe just because the
accesses are via different types

Noticed this while generalizing the code for loop distribution.

I confirmed with Arnold that this was indeed a bug and managed to create
a testcase.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230647 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-26 17:58:48 +00:00
Adam Nemet
5a51d864b9 [LoopAccesses] Add command-line option for RuntimeMemoryCheckThreshold
Also remove the somewhat misleading initializers from
VectorizationFactor and VectorizationInterleave.  They will get
initialized with the default ctor since no cl::init is provided.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230608 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-26 04:39:09 +00:00
Adam Nemet
989a0200c2 [LoopAccesses] LAA::getInfo to use const reference for stride parameter
And other required const-correctness fixes to make this work.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230289 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-24 00:41:59 +00:00
Adam Nemet
b7e0193c4d [LoopAccesses] Change LAA:getInfo to return a constant reference
As expected, this required a few more const-correctness fixes.

Based on Hal's feedback on D7684.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229899 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:21 +00:00
Adam Nemet
c182ce09e9 [LoopAccesses] Add -analyze support
The LoopInfo in combination with depth_first is used to enumerate the
loops.

Right now -analyze is not yet complete.  It only prints the result of
the analysis, the report and the run-time checks.  Printing the unsafe
depedences will require a bit more reshuffling which I'd like to do in a
follow-on to this patchset.  Unsafe dependences are currently checked
via -debug-only=loop-accesses in the new test.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229898 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:19 +00:00
Adam Nemet
4db669fb26 [LoopAccesses] Split out LoopAccessReport from VectorizerReport
The only difference between these two is that VectorizerReport adds a
vectorizer-specific prefix to its messages.  When LAA is used in the
vectorizer context the prefix is added when we promote the
LoopAccessReport into a VectorizerReport via one of the constructors.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229897 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:15 +00:00
Adam Nemet
7d39ae845d [LoopAccesses] Add missing const to APIs in VectorizationReport
When I split out LoopAccessReport from this, I need to create some temps
so constness becomes necessary.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229896 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:13 +00:00
Adam Nemet
5c4c262b3c [LoopAccesses] Add canAnalyzeLoop
This allows the analysis to be attempted with any loop.  This feature
will be used with -analysis.  (LV only requests the analysis on loops
that have already satisfied these tests.)

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229895 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:10 +00:00
Adam Nemet
9fdb32eb84 [LoopAccesses] Change debug messages from LV to LAA
Also add pass name as an argument to VectorizationReport::emitAnalysis.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229894 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:07 +00:00
Adam Nemet
0ea25c2e64 [LoopAccesses] Create the analysis pass
This is a function pass that runs the analysis on demand.  The analysis
can be initiated by querying the loop access info via LAA::getInfo.  It
either returns the cached info or runs the analysis.

Symbolic stride information continues to reside outside of this analysis
pass. We may move it inside later but it's not a priority for me right
now.  The idea is that Loop Distribution won't support run-time stride
checking at least initially.

This means that when querying the analysis, symbolic stride information
can be provided optionally.  Whether stride information is used can
invalidate the cache entry and rerun the analysis.  Note that if the
loop does not have any symbolic stride, the entry should be preserved
across Loop Distribution and LV.

Since currently the only user of the pass is LV, I just check that the
symbolic stride information didn't change when using a cached result.

On the LV side, LoopVectorizationLegality requests the info object
corresponding to the loop from the analysis pass.  A large chunk of the
diff is due to LAI becoming a pointer from a reference.

A test will be added as part of the -analyze patch.

Also tested that with AVX, we generate identical assembly output for the
testsuite (including the external testsuite) before and after.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229893 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:04 +00:00
Adam Nemet
093a04b6d6 [LoopAccesses] Cache the result of canVectorizeMemory
LAA will be an on-demand analysis pass, so we need to cache the result
of the analysis.  canVectorizeMemory is renamed to analyzeLoop which
computes the result.  canVectorizeMemory becomes the query function for
the cached result.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229892 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:00 +00:00
Adam Nemet
7b507eb2a5 [LoopAccesses] Stash the report from the analysis rather than emitting it
The transformation passes will query this and then emit them as part of
their own report.  The currently only user LV is modified to do just
that.

This is part of the patchset that converts LoopAccessAnalysis into an
actual analysis pass.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229891 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:14:56 +00:00