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
There is no need for other passes to access the code-generator command-line
option. Hence, drop it from the header to simplify the interface.
llvm-svn: 235866
This option is enabled since a long time and there does not seem to be a
situation in which we would not want to print alias scopes. Remove this option
to reduce the set of command-line option combinations that may expose bugs.
llvm-svn: 235861
We moved this implementation into the header file to share it between
the CLooG and isl code generator. As the CLooG code generator was dropped,
the implementation can be folded back into the .cpp file.
No functional change intended.
llvm-svn: 235860
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
I just learned that target triples prevent test cases to be run on other
architectures. Polly test cases are until now sufficiently target independent
to not require any target triples. Hence, we drop them.
llvm-svn: 235384
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
This change is a step towards using a single isl_schedule object throughout
Polly. At the moment the schedule is just constructed from the flat
isl_union_map that defines the schedule. Later we will obtain it directly
from the scop and potentially obtain a schedule with a non-trivial internal
structure that will allow faster dependence analysis.
llvm-svn: 235378
isl_union_map_compute_flow() has been replaced by
isl_union_access_info_compute_flow(). This change does not intend to
change funcitonality, yet. However, it will allow us to pass in subsequent
changes schedule trees to the dependence analysis instead of flat schedules.
This should speed up dependence analysis for important cases significantly.
llvm-svn: 235373
Otherwise, instructions in different functions that share the same pointer (due
to earlier modifications), might get assigned incorrect memory access
information (belonging to instructions in previous functions), which can result
in arbitrary memory corruption and assertion failures.
This fixes llvm.org/PR23160 and possibly also llvm.org/PR23167.
Note: InsnToMemAcc is a global variable that should never have existed in the
first place. We will clean this up in a subsequent patch.
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Debugged-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 235254
This will allow the ScopInfo to build the polyhedral representation for
non-affine regions that contain loops. Such loops are basically not visible
in the SCoP representation. Accesses that are variant in such loops are
therefor represented as non-affine accesses.
Differential Revision: http://reviews.llvm.org/D8153
llvm-svn: 234713
This will allow the ScopDetection to detect non-affine regions that
contain loops. All loops contained will be collected and are
accessible to later passes in order to adjust the access functions.
As the loops are non-affine and will not be part of the polyhedral
representation later, all accesses that are variant in these loops
have to be over approximated as non-affine accesses. They are
therefore handled the same way as other non-affine accesses.
Additionally, we do not count non-affine loops for the profitability
heuristic, thus a region with only a non-affine loop will only be
detected if the general detection of loop free regions is enabled.
Differential Revision: http://reviews.llvm.org/D8152
llvm-svn: 234711
This change ensures that we sign-extend integer types in case non-matching
operands are encountered when generating a multi-dimensional access offset.
This fixes http://llvm.org/PR23124
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 234122
As soon as one operand of the product is invalid, the entire product is invalid.
This happens for example if one of the operands is not loop-invariant.
This fixes http://llvm.org/PR23125
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com
llvm-svn: 234119
We do not have buildbots or anything that tests this functionality, hence it
most likely bitrots. People interested to use this functionality can always
recover it from svn history.
llvm-svn: 233570
This allows us to delinerize code such as:
A[][n]
for (i
for (j
A[i][n-j-1] = ...
which would previously have been delinearize to an access A[i+1][-j-1].
To recover the correct access we apply the piecewise expression:
{ A[i][j] -> A[i-1][i+N]: i < 0; A[i][j] -> A[i][i]: i >= 0}
This approach generalizes to higher dimensions.
llvm-svn: 233566
Tobias Grosser