llvm-svn: 210811

In general this fixes ambiguity that can arise from using
a different namespace that declares the same symbols as
we do.

One example inside llvm would be:
  createIndVarSimplifyPass(..);

Which can be found in:
  llvm/Transforms/Scalar.h
and
  polly/LinkAllPasses.h

llvm-svn: 210755

llvm-svn: 210754

Fixes #19976.

The error log does not contain an error, in case we reject a candidate
without generating a diagnostic message by using invalid<>(...). This is
the case for the top-level region of a function.

The patch comes without a test-case because adding a useful one requires
additional code just for triggering it. Before the patch it would only trigger,
if we try to print the CFG with Scop error annotations.

llvm-svn: 210753

llvm-svn: 210752

llvm-svn: 210170

llvm-svn: 210124

Without this patch, the testcase would fail on the delinearization of the second
array:

; void foo(long n, long m, long o, double A[n][m][o]) {
;   for (long i = 0; i < n; i++)
;     for (long j = 0; j < m; j++)
;       for (long k = 0; k < o; k++) {
;         A[i+3][j-4][k+7] = 1.0;
;         A[i][0][k] = 2.0;
;       }
; }

; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[3 + i0, -4 + i1, 7 + i2] };
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };

Here is the output of FileCheck on the testcase without this patch:

; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
         ^
<stdin>:26:2: note: possible intended match here
 [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[o0] };
 ^

It is possible to find a good delinearization for A[i][0][k] only in the context
of the delinearization of both array accesses.

There are two ways to delinearize together all array subscripts touching the
same base address: either duplicate the code from scop detection to first gather
all array references and then run the delinearization; or as implemented in this
patch, use the same delinearization info that we computed during scop detection.

llvm-svn: 210117

+ CL-option --polly-tile-sizes=<int,...,int>
  The i'th value is used as a tile size for dimension i, if
  there is no i'th value, the value of --polly-default-tile-size is
  used

+ CL-option --polly-default-tile-size=int
  Used if no tile size is given for a dimension i

+ 3 Simple testcases

llvm-svn: 209753

llvm-svn: 209710

llvm-svn: 209696

Instead of relying on the delinearization to infer the size of an element,
compute the element size from the base address type. This is a much more precise
way of computing the element size than before, as we would have mixed together
the size of an element with the strides of the innermost dimension.

llvm-svn: 209695

llvm-svn: 209584

Support a 'keep-going' mode for the ScopDetection. In this mode, we just keep
on detecting, even if we encounter an error.

This is useful for diagnosing SCoP candidates. Sometimes you want all the
errors. Invalid SCoPs will still be refused in the end, we just refuse to
abort on the first error.

llvm-svn: 209574

Use the new ScopDetectionDiagnostics to implement
the same functionality.

llvm-svn: 209573

This stores all RejectReasons created for one region
in a RejectLog inside the DetectionContext. For now
this only keeps track of the last error.

A separate patch will enable the tracking of all errors.
This patch itself does no harm (yet).

llvm-svn: 209572

We don't want the Statistic variables in every module that
includes the diagnostics.

llvm-svn: 209571

SVN r209103 removed the OwningPtr variant of the MemoryBuffer APIs.  Switch to
the equivalent std::unique_ptr versions.  This should clear up the build bots.

llvm-svn: 209104

llvm-svn: 208626

collect terms from affine and non affine memory accesses

llvm-svn: 208616

llvm-svn: 208457

This fixes the compilation of our GPGPU code generation experiment in Polly.

Contributed-by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 208287

llvm-svn: 208191

llvm-svn: 208190

Contributed-by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 208181

Contributed-by: Yabin Hu <yabin.hwu@gmail.com>
llvm-svn: 208180

llvm-svn: 207618

llvm-svn: 206903

llvm-svn: 206898

definition below all of the header #include lines, Polly edition.

If you want to know more details about this, you can see the recent
commits to Debug.h in LLVM. This is just the Polly segment of a cleanup
I'm doing globally for this macro.

llvm-svn: 206852

Commit r206510 falsely advertised to fix the load cases, even though it only
fixed the store case. This commit adds the same fix for the load case including
the missing test coverage.

llvm-svn: 206577

Even tough we may want to generate a vector load, the address from which to load
still is a scalar. Make sure even if previous address computations may have been
vectorized, that the addresses are also available as scalars.

This fixes http://llvm.org/PR19469



Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206510

llvm-svn: 206361

llvm-svn: 206333

Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 206332

llvm-svn: 206329

in r206312, but others don't seem to show up on build bots? Unsure of
why, they showed up for me.

llvm-svn: 206326

The following example shows a non-parallel loop

void f(int a[]) {
  int i;
  for (i = 0; i < 10; ++i)
    A[i] = A[i+5];
}

which, in case we import a schedule that limits the iteration domain
to 0 <= i < 5, becomes parallel. Previously we crashed in such cases, now we
just recognize it as parallel.

This fixes http://llvm.org/PR19435



Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206318

llvm-svn: 206312

This fixes PR19421.

Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206156