This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276246

This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276245

This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276244

llvm commonly adds a comment to the closing brace of a namespace to indicate
which namespace is closed. clang-tidy provides with llvm-namespace-comment
a handy tool to check for this habit. We use it to ensure we consitently use
namespace comments in Polly.

There are slightly different styles in how namespaces are closed in LLVM. As
there is no large difference between the different comment styles we go for the
style clang-tidy suggests by default.

To reproduce this fix run:

for i in `ls tools/polly/lib/*/*.cpp`; \
  clang-tidy -checks='-*,llvm-namespace-comment' -p build $i -fix \
  -header-filter=".*"; \
done

This cleanup was suggested by Eugene Zelenko <eugene.zelenko@gmail.com> in
http://reviews.llvm.org/D21488 and was split out to increase readability.

llvm-svn: 273621

  Created a new pass ScopInfoRegionPass. As name suggests, it is a
  region pass and it is there to preserve compatibility with our
  existing Polly passes.  ScopInfoRegionPass will return a SCoP object
  for a valid region while the creation of the SCoP stays in the
  ScopInfo class.

Contributed-by: Utpal Bora <cs14mtech11017@iith.ac.in>
Reviewed-by: Tobias Grosser <tobias@grosser.es&gt;,>
               Johannes Doerfert <doerfert@cs.uni-saarland.de>

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

llvm-svn: 271259

llvm-svn: 270421

llvm-svn: 262591

When importing a schedule, do not verify the load/store alignment of
scalar accesses. Scalar loads/store are always created newly in code
generation with no alignment restrictions. Previously, scalar alignment
was checked if the access instruction happened to be a LoadInst or
StoreInst, but only its array (MK_Array) access is relevant.

This will be implicitly unit-tested when the access instruction of a
value read can be nullptr.

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

llvm-svn: 257904

llvm-svn: 256151

  The changes affect methods that are part of the Pass interface and
  include:
    - Comments that describe the methods purpose.
    - A consistent use of the keywords override and virtual.
  Additionally, the printScop method is now optional and removed from
  SCoP passes that do not implement it.

llvm-svn: 248685

Originally, we disallowed the import of multi-dimensional access functions due
to our code generation not supporting the generation of new address expressions
for multi-dimensional memory accesses. When building our run-time alias check
infrastructure we added code generation support for multi-dimensional address
calculations.  Hence, we can now savely allow the import of new
multi-dimensional access functions.

llvm-svn: 246917

Instead of flat schedules, we now use so-called schedule trees to represent the
execution order of the statements in a SCoP. Schedule trees make it a lot easier
to analyze, understand and modify properties of a schedule, as specific nodes
in the tree can be choosen and possibly replaced.

This patch does not yet fully move our DependenceInfo pass to schedule trees,
as some additional performance analysis is needed here. (In general schedule
trees should be faster in compile-time, as the more structured representation
is generally easier to analyze and work with). We also can not yet perform the
reduction analysis on schedule trees.

For more information regarding schedule trees, please see Section 6 of
https://lirias.kuleuven.be/handle/123456789/497238

llvm-svn: 242130

We now verify that memory access functions imported via JSON are indeed defined
for the full iteration domain. Before this change we accidentally imported
memory mappings such as i -> i / 127, which only defined a mapped for values of
i that are evenly divisible by 127, but which did not define any mapping for the
remaining values, with the result that isl just generated an access expression
that had undefined behavior for all the unmapped values.

In the incorrect test cases, we now either use floor(i/127) or we use p/127 and
provide the information that p is indeed a multiple of 127.

llvm-svn: 239024

David Blaike suggested this as an alternative to the use of owningptr(s) for our
memory management, as value semantics allow to avoid the additional interface
complexity caused by owningptr while still providing similar memory consistency
guarantees. We could also have used a std::vector, but the use of std::vector
would yield possibly changing pointers which currently causes problems as for
example the memory accesses carry pointers to their parent statements. Such
pointers should not change.

Reviewer: jblaikie, jdoerfert

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

llvm-svn: 238290

llvm-svn: 238090

Upcoming revisions of isl require us to include header files explicitly, which
have previously been already transitively included. Before we add them, we sort
the existing includes.

Thanks to Chandler for sort_includes.py. A simple, but very convenient script.

llvm-svn: 236930

This change adds location information for the detected regions in Polly when the
required debug information is available.

The JSCOP output format is extended with a "location" field which contains the
information in the format "source.c:start-end"

The dot output is extended to contain the location information for each nested
region in the analyzed function.

As part of this change, the existing getDebugLocation function has been moved
into lib/Support/ScopLocation.cpp to avoid having to include
polly/ScopDetectionDiagnostics.h.

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



Contributed-by: Roal Jordans <r.jordans@tue.nl>
llvm-svn: 236393

When reading parameters from a JSON file parameters with identical names
may be related to different isl_ids, which then causes isl to treat them
as differnet objects. This does not cause issues at the moment, but has
shown problematic in subsequent schedule tree changes.

This commit will be tested by the following changes.

llvm-svn: 235588

In Polly we used both the term 'scattering' and the term 'schedule' to describe
the execution order of a statement without actually distinguishing between them.
We now uniformly use the term 'schedule' for the execution order.  This
corresponds to the terminology of isl.

History: CLooG introduced the term scattering as the generated code can be used
as a sequential execution order (schedule) or as a parallel dimension
enumerating different threads of execution (placement). In Polly and/or isl the
term placement was never used, but we uniformly refer to an execution order as a
schedule and only later introduce parallelism. When doing so we do not talk
about about specific placement dimensions.

llvm-svn: 235380

llvm-svn: 233326

llvm-svn: 231362

  The new Dependences struct in the DependenceInfo holds all information
  that was formerly part of the DependenceInfo. It also provides the
  same interface for the user to access this information.

  This is another step to a more general ScopPass interface that does
  allow multiple SCoPs to be "in flight".

llvm-svn: 231327

  We rename the Dependences pass to DependenceInfo as a first step to a
  caching pass policy. The new DependenceInfo pass will later provide
  "Dependences" for a SCoP.

  To keep consistency the test folder is renamed too.

llvm-svn: 231308

llvm-svn: 230902

llvm-svn: 230900

  This is the first step in the interface simplification.

llvm-svn: 230897

  This patch does not change the semantic on it's own. However, the
  dependence analysis as well as dce will now use the newest available
  access relation for each memory access, thus if at some point the json
  importer or any other pass will run before those two and set a new
  access relation the behaviour will be different. In general it is
  unclear if the dependence analysis and dce should be run on the old or
  new access functions anyway. If we need to access the original access
  function from the outside later, we can expose the getter again.

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

llvm-svn: 219612

  We restricted the new access functions to be a subset of the old one
  because we want to keep the alignment, however if the alignment is
  "not special", thus the default for the type, we can allow any access.


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

llvm-svn: 219503

  This class allows to store information about the arrays in the SCoP.
  For each base pointer in the SCoP one object is created storing the
  type and dimension sizes of the array. The objects can be obtained via
  the SCoP, a MemoryAccess or the isl_id associated with the output
  dimension of a MemoryAccess (the description of what is accessed).

  So far we use the information in the IslExprBuilder to create the
  right base type before indexing into the base array. This fixes the
  bug http://llvm.org/bugs/show_bug.cgi?id=21113 (both test cases are
  included). On top of that we can now build runtime alias checks for
  delinearized arrays as the dimension sizes are also part of the
  ScopArrayInfo objects.

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

llvm-svn: 219077

  This also forbids the json importer to access other memory locations
  than the original instruction as we to reuse the alignment of the
  original load/store.

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

llvm-svn: 218883

llvm-svn: 216394

llvm-svn: 212609

llvm-svn: 212412

+ Added const iterator version
+ Changed name to begin/end to allow range loops
+ Changed call sites to range loops
+ Changed typename to (const_)iterator

llvm-svn: 210927

llvm-svn: 210847

llvm-svn: 210811

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: 207618

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

llvm-svn: 202056