| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202048
|
|
|
|
|
|
| |
This should fix the buildbots.
llvm-svn: 198859
|
|
|
|
|
|
| |
directory to their proper homes.
llvm-svn: 198691
|
|
|
|
|
|
|
|
|
| |
In case we detect that the schedule the user wants to import is invalid we
refuse it _and_ free the isl_maps containing it.
Another bug found thanks to Rafael.
llvm-svn: 187339
|
|
|
|
| |
llvm-svn: 186248
|
|
|
|
| |
llvm-svn: 184655
|
|
|
|
| |
llvm-svn: 181297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the new cl::OptionCategory support to move the Polly options into a separate
option category. The aim is to hide most options and show by default only the
options a user needs to influence '-O3 -polly'. The available options probably
need some care, but here is the current status:
Polly Options:
Configure the polly loop optimizer
-enable-polly-openmp - Generate OpenMP parallel code
-polly - Enable the polly optimizer (only at -O3)
-polly-no-tiling - Disable tiling in the scheduler
-polly-only-func=<function-name> - Only run on a single function
-polly-report - Print information about the activities
of Polly
-polly-vectorizer - Select the vectorization strategy
=none - No Vectorization
=polly - Polly internal vectorizer
=unroll-only - Only grouped unroll the vectorize
candidate loops
=bb - The Basic Block vectorizer driven by
Polly
llvm-svn: 181295
|
|
|
|
|
|
|
| |
clang-format become way more stable. This time we mainly reformat function
signatures.
llvm-svn: 181294
|
|
|
|
| |
llvm-svn: 179160
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this commit, polly is clang-format clean. This can be tested with
'ninja polly-check-format'. Updates to clang-format may change this, but the
differences will hopefully be both small and general improvements to the
formatting.
We currently have some not very nice formatting for a couple of items, DEBUG()
stmts for example. I believe the benefit of being clang-format clean outweights
the not perfect layout of this code.
llvm-svn: 177796
|
|
|
|
| |
llvm-svn: 171224
|
|
|
|
|
|
|
|
| |
Store a pointer to each ScopStmt in the isl_id associated with the space of its
domain. This will later allow us to recover the statement during code
generation with isl.
llvm-svn: 157607
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The FinalRead statement represented a virtual read that is executed after the
SCoP. It was used when we verified the correctness of a schedule by checking if
it yields the same FLOW dependences as the original code. This is only works, if
we have a final read that reads all memory at the end of the SCoP.
We now switched to just checking if a schedule does not introduce negative
dependences and also consider WAW WAR dependences. This restricts the schedules
a little bit more, but we do not have any optimizer that would calculate a more
complex schedule. Hence, for now final reads are obsolete.
llvm-svn: 152319
|
|
|
|
|
|
|
| |
Instead we switch to the recommended getName(). This fixes compilation with
recent versions of LLVM.
llvm-svn: 144909
|
|
|
|
|
|
|
|
|
|
| |
The new isl_id support for parmeters created problems when importing new
access functions. Even though the parameters had the same names,
they were mapped to different ids and where therefore incompatible.
We copy the ids now from the old parameter dimensions. This fixes the
problem.
llvm-svn: 144642
|
|
|
|
| |
llvm-svn: 144639
|
|
|
|
| |
llvm-svn: 144638
|
|
|
|
|
|
|
|
| |
Also take the chance and rename access functions to access relations. This is
because we do not only allow plain functions to describe an access, but we
can have any access relation that can be described with linear constraints.
llvm-svn: 141257
|
|
|
|
| |
llvm-svn: 141254
|
|
|
|
|
|
|
|
| |
Polly should now be compiled with CLooG 0c252c88946b27b7b61a1a8d8fd7f94d2461dbfd
and isl 56b7d238929980e62218525b4b3be121af386edf. The most convenient way to
update is utils/checkout_cloog.sh.
llvm-svn: 141251
|
|
|
|
|
|
|
|
|
| |
Because of me not understanding the LLVM pass structure well, I did not find a
good way to allocate isl_ctx and to free it later without getting issues with
reference counting. I now found this place, such that we can free isl_ctx. This
patch also fixes the memory leaks that were ignored beforehand.
llvm-svn: 138204
|
|
|
|
|
|
|
| |
Support for generating code for an access function change which is
a constant is added.
llvm-svn: 137603
|
|
|
|
|
|
|
| |
The changed access relations imported from JSCOP file is shown
as output of -analyze pass.
llvm-svn: 136774
|
|
|
|
|
|
|
| |
While iterating through the memory accesses in JSCOP file
the inner loop index was not initialized to zero.
llvm-svn: 135340
|