The alias to the array element is read-only and a primitive type (pointer),
therefore use the value directly instead of a reference to it.

llvm-svn: 281311

Store the size of the outermost dimension in case of newly created arrays that require memory allocation.

We do not need the size of the outermost dimension in most cases, but if we
allocate memory for newly created arrays, that size is needed.

Reviewed-by: Michael Kruse <llvm@meinersbur.de>

Differential Revision: https://reviews.llvm.org/D23991

llvm-svn: 281234

When running the clang static analyser to check for memory issues, this code
originally showed a double free, as the analyser was unable to understand that
isl_set_free always returns NULL and consequently later uses of the isl object
we just freed will never be reached. Without this knowledge, the analyser has
to issue a warning.

We refactor the code to make it clear that for empty maps the current loop
iteration is aborted.

llvm-svn: 280940

llvm-svn: 280923

... but instead rely on the assumptions that we derive for load/store
instructions.

Before we were able to delinearize arrays, we used GEP pointer instructions
to derive information about the likely range of induction variables, which
gave us more freedom during loop scheduling. Today, this is not needed
any more as we delinearize multi-dimensional memory accesses and as part
of this process also "assume" that all accesses to these arrays remain
inbounds. The old derive-assumptions-from-GEP code has consequently become
mostly redundant. We drop it both to clean up our code, but also to improve
compile time. This change reduces the scop construction time for 3mm in
no-asserts mode on my machine from 48 to 37 ms.

llvm-svn: 280601

LLVM's coding guideline suggests to not use @brief for one-sentence doxygen
comments to improve readability. Switch this once and for all to ensure people
do not copy @brief comments from other parts of Polly, when writing new code.

llvm-svn: 280468

Change the code around setNewAccessRelation to allow to use a an existing array
element for memory instead of an ad-hoc alloca. This facility will be used for
DeLICM/DeGVN to convert scalar dependencies into regular ones.

The changes necessary include:
- Make the code generator use the implicit locations instead of the alloca ones.
- A test case
- Make the JScop importer accept changes of scalar accesses for that test case.
- Adapt the MemoryAccess interface to the fact that the MemoryKind can change.
  They are named (get|is)OriginalXXX() to get the status of the memory access
  before any change by setNewAccessRelation() (some properties such as
  getIncoming() do not change even if the kind is changed and are still
  required). To get the modified properties, there is (get|is)LatestXXX(). The
  old accessors without Original|Latest become synonyms of the
  (get|is)OriginalXXX() to not make functional changes in unrelated code.

Differential Revision: https://reviews.llvm.org/D23962

llvm-svn: 280408

There are some constraints on maps that can be access relations. In builds with assertions enabled, verify

  - The access domain is the same space as the statement's domain (modulo parameters).
  - Whether an access is defined for every instance of the statement. (codegen does not yet support partial access relations)
  - Whether the access range links to an array, represented by a ScopArrayInfo.
  - The number of access dimensions equals the dimensions of the array.
  - The array is not an indirect access. (also not supported by codegen)

Differential Revision: https://reviews.llvm.org/D23916

llvm-svn: 280404

llvm-svn: 280343

getAccessFunctions() is dead code and the 'BB' argument
of getOrCreateAccessFunctions() is not used. This patch deletes
getAccessFunctions and transforms AccFuncMap into
a std::vector<std::unique_ptr<MemoryAccess>> AccessFunctions.

Reviewed-by: Tobias Grosser <tobias@grosser.es>

Differential Revision: https://reviews.llvm.org/D23759

llvm-svn: 279394

llvm-svn: 277569

Extend the jscop interface to allow the user to declare new arrays and to reference these arrays from access expressions

Extend the jscop interface to allow the user to export arrays. It is required
that already existing arrays of the list of arrays correspond to arrays
of the SCoP. Each array that is appended to the list will be newly created.
Furthermore, we allow the user to modify access expressions to reference
any array in case it has the same element type.

Reviewed-by: Tobias Grosser <tobias@grosser.es>

Differential Revision: https://reviews.llvm.org/D22828

llvm-svn: 277263

  Do not process SCoPs with infeasible runtime context in the new
  ScopInfoWrapperPass. Do not compute dependences for such SCoPs in the new
  DependenceInfoWrapperPass.

Patch by Utpal Bora <cs14mtech11017@iith.ac.in>

Differential Revision: https://reviews.llvm.org/D22402

llvm-svn: 276631

llvm-svn: 276444

Commit r275056 introduced a gcc compile failure due to us using two
types named 'Type', the first being the newly introduced member variable
'Type' the second being llvm::Type. We resolve this issue by renaming
the newly introduced member variable to AccessType.

llvm-svn: 275057

Summary:
With a struct we can use named accessors instead of generic std::get<3>()
calls. This increases readability of the source code.

Reviewers: jdoerfert

Subscribers: pollydev, llvm-commits

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

llvm-svn: 275056

We now compute the invalid context of memory accesses only for the domain under
which the memory access is executed. Without limiting ourselves to this
restricted domain, invalid accesses outside of the domain of actually executed
statement instances may result in the execution domain of the statement to
become empty despite the fact that the statement will actually be executed. As a
result, such scops would use unitialized values for their computations which
results in incorrect computations.

This fixes http://llvm.org/PR27944 and unbreaks the
-polly-position=before-vectorizer buildbots.

llvm-svn: 275053

For llvm the memory accesses from nonaffine loops should be visible,
however for polly those nonaffine loops should be invisible/boxed.

This fixes llvm.org/PR28245

Cointributed-by: Huihui Zhang <huihuiz@codeaurora.org>

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

llvm-svn: 274842

Without this change it is not possible for isl to parse the resulting objects
from their string representation.

llvm-svn: 274350

It is only used internally by the ScopInfo pass. By moving it into its
own header file we avoid it being processed that use only ScopInfo.

llvm-svn: 273983

The methods in ScopBuilder are used for the construction of a Scop,
while the remaining classes of ScopInfo are required by all passes that
use Polly's polyhedral analysis.

llvm-svn: 273982

This function is used by both ScopInfo and ScopBuilder. A common
location for this function is required when ScopInfo and ScopBuilder are
separated into separate files in the next commit.

llvm-svn: 273981

This patch adds a new function pass ScopInfoWrapperPass so that the
polyhedral description of a region, the SCoP, can be constructed and
used in a function pass.

Patch by Utpal Bora <cs14mtech11017@iith.ac.in>

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

llvm-svn: 273856

  1. SCoP object is not owned by ScopBuilder. It just creates a SCoP and
     hand over ownership through getScop() method.
  2. ScopInfoRegionPass owns the SCoP object for a given region.

Patch by Utpal Bora <cs14mtech11017@iith.ac.in>

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

llvm-svn: 273855

llvm-svn: 271890

llvm-svn: 271522

Contributed-by: Utpal Bora <cs14mtech11017@iith.ac.in>
Reviewed-by: Michael Kruse <meinersbur@googlemail.com>
               Johannes Doerfert <doerfert@cs.uni-saarland.de>

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

llvm-svn: 271521

llvm-svn: 271511

  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

This exposes the more basic operation for use by code not related to
invariant code hoisting.

llvm-svn: 270438

Found by clang static analyzer (http://llvm.org/reports/scan-build/)
and Visual Studio.

llvm-svn: 270432

llvm-svn: 270429

llvm-svn: 270428

llvm-svn: 270427

  This allows to use the SCoP directly for various queries,
  thus to hide the underlying region more often.

llvm-svn: 270426

llvm-svn: 270424

llvm-svn: 270421

  Before this patch we bailed if a required invariant load was potentially
  overwritten. However, now we will optimistically assume it is actually
  invariant and, to this end, restrict the valid parameter space as well as the
  execution context with regards to potential overwrites of the location.

llvm-svn: 270416

  Since the base pointer of a possibly aliasing pointer might not alias
  with any other pointer it (the base pointer) might not be tagged as
  "required invariant". However, we need it do be in order to compare
  the accessed addresses of the derived (possibly aliasing) pointer.

  This patch also tries to clean up the load hoisting a little bit.

llvm-svn: 270412

llvm-svn: 270410