This change has three major advantages:
- The ScopInfo becomes smaller.
- It allows to use the SCEVAffinator from outside the ScopInfo.
- A member object allows state which in turn allows e.g., caching.
Differential Revision: http://reviews.llvm.org/D9099
llvm-svn: 244730
In order to find the llvm-obj directory it has to be (or a soft link
to it) at one of the following locations:
${POLLY_SRC_DIR}/build
${POLLY_SRC_DIR}.build
${POLLY_SRC_DIR}-build
s/${POLLY_SRC_DIR}/src/build
Alternatively, the environment variable $POLLY_BIN_DIR can point to it.
llvm-svn: 244727
Before we only modeled PHI nodes if at least one incoming basic block was itself
part of the region, now we always model them except if all of their operands are
part of a single non-affine subregion which we model as a black-box.
This change only affects PHI nodes in the entry block, that have exactly one
incoming edge. Before this change, we did not model them and as a result code
generation would not know how to code generate them. With this change, code
generation can code generate them like any other PHI node.
This issue was exposed by r244606. Before this change simplifyRegion would have
moved these PHI nodes out of the SCoP, so we would never have tried to code
generate them. We could implement this behavior again, but changing the IR
after the scop has been modeled and transformed always adds a risk of us
invalidating earlier analysis results. It seems more save and overall also more
consistent to just model and handle this one-entry-edge PHI nodes like any
other PHI node in the scop.
Solution proposed by: Michael Kruse <llvm@meinersbur.de>
llvm-svn: 244721
This one was extracted from the test-suite's pifft and caused a
miscompilation because a scalar was not written to its alloca address.
llvm-svn: 244720
In order to have a valid region analysis, we assign all newly created blocks to the parent of the scop's region. This is correct for any pre-existing regions (including the scop's region and its parent), but does not discover any region inside the generated code. For Polly this is not necessary because we do not want to re-run Polly on its own generated code anyway.
Reviewers: grosser
Part of Differential Revision: http://reviews.llvm.org/D11867
llvm-svn: 244608
The previous code had several problems:
For newly created BasicBlocks it did not (always) call RegionInfo::setRegionFor in order to update its analysis. At the moment RegionInfo does not verify its BBMap, but will in the future. This is fixed by determining the region new BBs belong to and set it accordingly. The new executeScopConditionally() requires accurate getRegionFor information.
Which block is created by SplitEdge depends on the incoming and outgoing edges of the blocks it connects, which makes handling its output more difficult than it needs to be. Especially for finding which block has been created an to assign a region to it for the setRegionFor problem above. This patch uses an implementation for splitEdge that always creates a block between the predecessor and successor. simplifyRegion has also been simplified by using SplitBlockPredecessors instead of SplitEdge. Isolating the entries and exits have been refectored into individual functions.
Previously simplifyRegion did more than just ensuring that there is only one entering and one exiting edge. It ensured that the entering block had no other outgoing edge which was necessary for executeScopConditionally(). Now the latter uses the alternative splitEdge implementation which can handle this situation so simplifyRegion really only needs to simplify the region.
Also, executeScopConditionally assumed that there can be no PHI nodes in blocks with one incoming edge. This is wrong and LCSSA deliberately produces such edges. However, previous passes ensured that there can be no such PHIs in exit nodes, but which will no longer hold in the future.
The new code that the property that it preserves the identity of region block (the property that the memory address of the BasicBlock containing the instructions remains the same; new blocks only contain PHI nodes and a terminator), especially the entry block. As a result, there is no need to update the reference to the BasicBlock of ScopStmt that contain its instructions because they have been moved to other basic blocks.
Reviewers: grosser
Part of Differential Revision: http://reviews.llvm.org/D11867
llvm-svn: 244606
RegionInfo::splitBlock did not update RegionInfo correctly. Specifically, it tried to make the new block the entry block if possible. This breaks for nested regions that have edges to the old block.
We simply do not change the entry block. Updating RegionInfo becomes trivial as both block will always be in the same region.
splitEntryBlockForAlloca makes use of the new splitBlock.
Reviewers: grosser
Part of Differential Revision: http://reviews.llvm.org/D11867
llvm-svn: 244600
Besides other changes this version of isl contains a fundamental fix to memory
corruption issues we have seen with imath-32 backed isl_ints.
This update also contains a fix that ensures that the schedule-tree based
version of isl's dependence analysis takes the domain of the schedule into
account.
llvm-svn: 244585
With a deque (or any other sequential container) it is not sound to
take the address of the elements when the container is still under
construction. With a pointer based container this is save.
llvm-svn: 244459
Summary: The extracted function buildBBScopStmt will be needed later to be invoked individually on the region's exit block.
Reviewers: grosser, jdoerfert
Subscribers: jdoerfert, llvm-commits, pollydev
Projects: #polly
Differential Revision: http://reviews.llvm.org/D11878
llvm-svn: 244443
Summary: The splitExitBlock function is never called. Going to replace its functionality in successive patches that do not modify the IR.
Reviewers: grosser
Subscribers: pollydev
Projects: #polly
Differential Revision: http://reviews.llvm.org/D11865
llvm-svn: 244404
Even though read-only accesses to scalars outside of a scop do not need to be
modeled to derive valid transformations or to generate valid sequential code,
but information about them is useful when we considering memory footprint
analysis and/or kernel offloading.
llvm-svn: 243981
This change is required to see the detected scops even in cases where there is
no other ScopInfo user after the ScopViewers. Before this change, when
running with -polly-optimizer=none -polly-code-generator=none detected scops
have not been shown.
llvm-svn: 243971
If set, this option instructs -view-scops and -polly-show to only print
functions that contain the specified string in their name. This allows to
look at the scops of a specific function in a large .ll file, without flooding
the screen with .dot graphs.
llvm-svn: 243882
We use the branch instruction as the location at which a PHI-node write takes
place, instead of the PHI-node itself. This allows us to identify the
basic-block in a region statement which is on the incoming edge of the PHI-node
and for which the write access was originally introduced. As a result we can,
during code generation, avoid generating PHI-node write accesses for basic
blocks that do not preceed the PHI node without having to look at the IR
again.
This change fixes a bug which was introduced in r243420, when we started to
explicitly model PHI-node reads and writes, but dropped some additional checks
that where still necessary during code generation to not emit PHI-node writes
for basic-blocks that are not on incoming edges of the original PHI node.
Compared to the code before r243420 the new code does not need to inspect the IR
any more and we also do not generate multiple redundant writes.
llvm-svn: 243852
The schedule map we derive from a schedule tree map may map statements into
schedule spaces of different dimensionality. This change adds zero padding
to ensure just a single schedule space is used and the translation from
a union_map to an isl_multi_union_pw_aff does not fail.
llvm-svn: 243849
SCEVExpander, which we are using during code generation, only allows
instructions as insert locations, but breaks in case BasicBlock->end() iterators
are passed to it due to it trying to obtain the basic block in which code should
be generated by calling Instruction->getParent(), which is not defined for
->end() iterators.
This change adds an assert to Polly that ensures we only pass valid instructions
to SCEVExpander and it fixes one case, where we used IRBuilder->SetInsertBlock()
to set an ->end() insert location which was later passed to SCEVExpander.
In general, Polly is always trying to build up the CFG first, before we actually
insert instructions into the CFG sceleton. As a result, each basic block should
already have at least one branch instruction before we start adding code. Hence,
always requiring the IRBuilder insert location to be set to a real instruction
should always be possible.
Thanks Utpal Bora <cs14mtech11017@iith.ac.in> for his help with test case
reduction.
llvm-svn: 243830
It is common practice to keep constructors lightweight. The reasons
include:
- The vtable during the constructor's execution is set to the static
type of the object, not to the vtable of the derived class. That is,
method calls behave differently in constructors and ordinary methods.
This way it is possible to call unimplemented methods of abstract
classes, which usually results in a segmentation fault.
- If an exception is thrown in the constructor, the destructor is not
called, potentially leaking memory.
- Code in constructors cannot be called in a regular way, e.g. from
non-constructor methods of derived classes.
- Because it is common practice, people may not expect the constructor
to do more than initializing data and skip them when looking for bugs.
Not all of these are applicable to LLVM (e.g. exceptions are disabled).
This patch refactors out the computational work in the constructors of
Scop and IslAst into regular init functions and introduces static
create-functions as replacement.
Differential revision: http://reviews.llvm.org/D11491
Reviewers: grosser, jdoerfert
llvm-svn: 243677
Such codes are not interesting to optimize and most likely never appear in the
normal compilation flow. However, they show up during test case reduction with
bugpoint and trigger -- without this change -- an assert in
polly::MemoryAccess::foldAccess(). It is better to detect them in
ScopDetection itself and just bail out.
Contributed-by: Utpal Bora <cs14mtech11017@iith.ac.in>
Reviewers: grosser
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D11425
llvm-svn: 243515
Schedule trees are a lot easier to work with, for both humans and machines. For
humans the more structured schedule representation is easier to reason about.
Together with the more abstract isl programming interface this can result in a
lot cleaner code (see this changeset). For machines, the structured schedule and
the fact that we now use explicit piecewise affine expressions instead of
integer maps makes it easier to generate code from this schedule tree. As a
result, we can already see a slight compile-time improvement -- for 3mm from
0m0.593s to 0m0.551s seconds (-7 %). More importantly, future optimizations such
as full-partial tile separation will most likely result in more streamlined code
to be generated.
Contributed-by: Roman Gareev <gareevroman@gmail.com>
llvm-svn: 243458
Summary:
When translating PHI nodes into memory dependences during code generation we
require two kinds of memory. 'Normal memory' as for all scalar dependences and
'PHI node memory' to store the incoming values of the PHI node. With this
patch we now mark and track these two kinds of memories, which we previously
incorrectly marked as a single memory object.
Being aware of PHI node storage makes code generation easier, as we do not need
to guess what kind of storage a scalar reference requires. This simplifies the
code nicely.
Reviewers: jdoerfert
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D11554
llvm-svn: 243420
We hoist statements that are used on both branches of an if-condition, shorten
and unify some variable names and fold some variable declarations into their
only uses. We also drop a comment which just describes the elements the loop
iterates over.
No functional change intended.
llvm-svn: 243291
Besides a couple of cleanups and refactorings in isl, this change set fixes a
couple of bugs in isl, that can cause issues during code generation.
llvm-svn: 243110
These test cases check whether Polly still gives the same results if
LICM runs before. Currently, it does not and therefore these cases are
expected fails.
llvm-svn: 243037
As specified in PR23888, run-time alias check generation is expensive
in terms of compile-time. This reduces the compile time by computing
minimal/maximal access only once for each base pointer
Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in>
llvm-svn: 243024
A similar patch will be upstreamed to ISL. We commit this ahead of time to
unblock people that are annoyed the permanent diffs we see in git.
llvm-svn: 243020
Put all Polly targets into a single "Polly" category (i.e.
solution folder). Previously there was no recognizable scheme and most
categories contained just one or two targets or targets didn't belong
to any category.
Reviewers: grosser
llvm-svn: 242779
Remove the polly_headers_do_not_build project. Visual Studio is capable
of finding the headers itself, although they are not listed explicitly.
For explicit listing, the headers should be added to the relevant
target.
Reviewers: grosser
llvm-svn: 242777
Query the isl_config.h macros recently added to ISL. One of it looks for
the ffs (find first set), whose functionality is available in Visual
Studio with _BitScanForward. Also add isl_ffs.c to the source files
which contains the implementation of ffs using _BitScanForward.
Reviewers: grosser
llvm-svn: 242770
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
Named isl sets can generally have any name if they remain within Polly, but only
certain strings can be parsed by isl. The new names we create ensure that we
can always copy-past isl strings from Polly to other isl tools, e.g. for
debugging.
llvm-svn: 241787
This updated contains various changes to isl, including improvements to the
AST generator. For Polly, the most important change is a fix that unbreaks
builds on darwin (reported by: Jack Howard)
llvm-svn: 241048
Summary: Adding the flag to C++ source files emits a warning, hence we set the compile flag depending on the file's language.
Reviewers: grosser
Subscribers: Meinersbur, pollydev, llvm-commits
Projects: #polly
Differential Revision: http://reviews.llvm.org/D10809
llvm-svn: 240986
This is very preliminary support, but it seems to work for the most common case.
When observing more/different test cases, we can work on generalizing this.
llvm-svn: 240955
As Polly got a lot faster after the small-integer-optimization imath
patch, we now increase the compute out to optimize larger kernels. This
should also expose additional slow-downs for us to address.
In LNT this gives us a 3.4x speedup on 3mm, at a cost of a 2x increase in
compile time (now 0.77s). reg_detect, oorafft and adi also show some compile
time increases. This compile time cost is divided between more time in isl and
more time in LLVM's backends due to increased code size (versioning and tiling).
llvm-svn: 240840
In case we have modulo operations in the access function (supported since
r240518), the assumptions generated to ensure array accesses remain within
bounds can contain existentially quantified dimensions which results in more
complex and more difficult to handle integer sets. As a result LNT's linpack
benchmark started to fail due to excessive compile time.
We now just drop the existentially quantified dimensions. This should be
generally save, but may result in less precise assumptions which may
consequently make us fall back to the original (unoptimized) code more often. In
practice, these cases probably do not appear to often.
I had difficulties to extract a good test case, but fortunately our LNT bots
cover this one well.
llvm-svn: 240775
This removes old code that has been disabled since several weeks and was hidden
behind the flags -disable-polly-intra-scop-scalar-to-array=false and
-polly-model-phi-nodes=false. Earlier, Polly used to translate scalars and
PHI nodes to single element arrays, as this avoided the need for their special
handling in Polly. With Johannes' patches adding native support for such scalar
references to Polly, this code is not needed any more. After this commit both
-polly-prepare and -polly-independent are now mostly no-ops. Only a couple of
simple transformations still remain, but they are scheduled for removal too.
Thanks again to Johannes Doerfert for his nice work in making all this code
obsolete.
llvm-svn: 240766
Summary:
With small integer optimization (short: sio) enabled, ISL uses 32 bit
integers for its arithmetic and only falls back to a big integer library
(in the case of Polly: IMath) if an operation's result is too large.
This gives a massive performance boost for most application using ISL.
For instance, experiments with ppcg (polyhedral source-to-source
compiler) show speed-ups of 5.8 (compared to plain IMath), respectively
2.7 (compared to GMP).
In Polly, a smaller fraction of the total compile time is taken by ISL,
but the speed-ups are still very significant. The buildbots measure
compilation speed-up up to 1.8 (oourafft, floyd-warshall, symm). All
Polybench benchmarks compile in at least 9% less time, and about 20%
less on average.
Detailed Polybench compile time results (median of 10):
correlation -25.51%
covariance -24.82%
2mm -26.64%
3mm -28.69%
atax -13.70%
bicg -10.78%
cholesky -40.67%
doitgen -11.60%
gemm -11.54%
gemver -10.63%
gesummv -11.54%
mvt -9.43%
symm -41.25%
syr2k -14.71%
syrk -14.52%
trisolv -17.65%
trmm -9.78%
durbin -19.32%
dynprog -9.09%
gramschmidt -15.38%
lu -21.77%
floyd-warshall -42.71%
reg_detect -41.17%
adi -36.69%
fdtd-2d -32.61%
fdtd-apml -21.90%
jacobi-1d-imper -9.41%
jacobi-2d-imper -27.65%
seidel-2d -31.00%
Reviewers: grosser
Reviewed By: grosser
Subscribers: Meinersbur, llvm-commits, pollydev
Projects: #polly
Differential Revision: http://reviews.llvm.org/D10506
llvm-svn: 240689
There were two issues:
* ISL's configure generates include/isl/stdint.h, not isl/stdint.h as
assumed. This is also changed in the CMake build.
* Need to pass --with-int=imath to ISL's configure; the default is gmp.
Polly's configure has been regenerated due to changing configure.ac
llvm-svn: 240657
Remainder operations with constant divisor can be modeled as quasi-affine
expression. This patch adds support for detecting and modeling them. We also
add a test that ensures they are correctly code generated.
This patch was extracted from a larger patch contributed by Johannes Doerfert
in http://reviews.llvm.org/D5293
llvm-svn: 240518
This makes the test cases nonaffine even if Polly some days gains support for
the srem instruction, an instruction which is currently not modeled but which
can clearly be modeled statically. A call to a function without definition
will always remain non-affine, as there is just insufficient static information
for it to be modeled more precisely.
llvm-svn: 240458
ISL with small integer optimization requires C99 to compile. gcc < 5.0
still uses C89 as default, so we need to enable the options to compile
in C99 mode.
This patch is preparing the actual activation of small integer
optimization.
Differential version: http://reviews.llvm.org/D10610
Reviewers: grosser
llvm-svn: 240322
ISL's ./configure examines the system for the stdint.h to include and
creates a header file that points to it. On C99-compatible system
#include <stdint.h>
is always valid such there no need for system introspection. This should
unbreak the build bots.
llvm-svn: 240315
The 'make dist' archive is not dependent on ./configure output and
contains a GIT_HEAD_ID file that identifies the version of ISL used.
None of the files added or removed are used part of Polly's build
process (except of GIT_HEAD_ID since the previous revision r240301). No
functional change intended.
llvm-svn: 240306
Currently the Polly repository contains the ISL sources with bogus
isl_config.h and gitversion.h. This is problematic. In this state a
macro
#define __attribute__(x)
becomes active in the source, leading to various problems e.g. when
included before system header files. This patch will instead generate
the two files specific to the host system at configure-time.
For CMake, we replicate the tests that ISL's configure performs using
try_compile(). In autotools build, we just invoke ISL's configure to
generate the two files. This consequently required regenerating
autoconf/configure.
'make dist' distributions of ISL contain a file GIT_HEAD_ID which
contains the version the distribution is derived from. The repository
files themselves do not contain such a hint. In a later commit we will
replace the isl directory by the contents of such a .tar.gz. It does
not contain the files imdrover.c iprime.c pi.c and rsamath.c currently
compiled into Polly, but not used and therefore are removed by this
patch.
In the long term we plan to generate a dedicated library for ISL instead
of adding its files to Polly.
This also does not yet include the switch to small-integer optimized ISL
nor enabling C99 mode required for the former. Those will come as well
in separate patches.
Differential version: http://reviews.llvm.org/D10603
Reviewers: grosser
llvm-svn: 240301
This was meant to committed in r240027, but was left behind because
svn, in contrast to git, only commits the changes in the directory you
are currently in.
llvm-svn: 240034
This version adds small integer optimization, but is not active by
default. It will be enabled in a later commit.
The schedule-fuse=min/max option has been replaced by the
serialize-sccs option. Adapting Polly was necessary, but retaining the
name polly-opt-fusion=min/max.
Differential Revision: http://reviews.llvm.org/D10505
Reviewers: grosser
llvm-svn: 240027
LLVM's instcombine already translates power-of-two sdivs that are known to be
exact to fast ashr instructions. Hence, there is no need to add this logic
ourselves.
Pointed-out-by: Johannes Doerfert
llvm-svn: 239025
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
floord(a,b) === a ashr log_2 (b) holds for positive and negative a's, but
shifting only makes sense for positive values of b. The previous patch did
not consider this as isl currently always produces postive b's. To avoid future
surprises, we check that b is positive and only then apply the optimization.
We also now correctly check the return value of the dyn-cast.
No additional test case, as isl currently does not produce negative
denominators.
Reported-by: David Majnemer <david.majnemer@gmail.com>
llvm-svn: 238927
Running indvar before Polly is useful as this eliminates zexts as they commonly
appear when a 32 bit induction variable (type int) was used on a 64 bit system.
These zexts confuse our delinearization and prevent for example the successful
delinearization of the nussinov kernel in polybench-c-4.1.
This fixes http://llvm.org/PR23426
Suggested-by: Xing Su <xsu.llvm@outlook.com>
llvm-svn: 238643
isl marks known non-negative numerators in modulo (and soon also division)
operations. We now exploit this by generating unsigned operations. This is
beneficial as unsigned operations with power-of-two denominators will be
translated by isl to fast bitshift or bitwise and operations.
llvm-svn: 238577
David Blaikie:
"find returns an iterator by value, so it's just added complexity/strangeness to
then use reference lifetime extension to give it the same semantics as if you'd
used a value type instead of a reference type."
llvm-svn: 238294
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
While looking through the test cases I realized we did not have a CHECK line
for a duplicate memory access which we may want to eliminate later. To ensure
we do not have (or later introduce) unnecessary memory accesses, we now tighten
the test cases to look for such a pattern (and add the CHECK: line that shows
the redundant memory access).
llvm-svn: 238227
The feature itself has been committed by Johannes in r238070. As this is the
way forward, we now enable it to ensure we get test coverage.
Thank you Johannes for this nice work!
llvm-svn: 238088
This ensures we pass all tests independently of how we set the options
-disable-polly-intra-scop-scalar-to-array and -polly-model-phi-nodes.
(At least if we enable both or disable both. Enabling them individually makes
little sense, as they will hopefully disappear soon anyhow).
llvm-svn: 238087
To reduce compile time and to allow more and better quality SCoPs in
the long run we introduced scalar dependences and PHI-modeling. This
patch will now allow us to generate code if one or both of those
options are set. While the principle of demoting scalars as well as
PHIs to memory in order to communicate their value stays the same,
this allows to delay the demotion till the very end (the actual code
generation). Consequently:
- We __almost__ do not modify the code if we do not generate code
for an optimized SCoP in the end. Thus, the early exit as well as
the unprofitable option will now actually preven us from
introducing regressions in case we will probably not get better
code.
- Polly can be used as a "pure" analyzer tool as long as the code
generator is set to none.
- The original SCoP is almost not touched when the optimized version
is placed next to it. Runtime regressions if the runtime checks
chooses the original are not to be expected and later
optimizations do not need to revert the demotion for that part.
- We will generate direct accesses to the demoted values, thus there
are no "trivial GEPs" that select the first element of a scalar we
demoted and treated as an array.
Differential Revision: http://reviews.llvm.org/D7513
llvm-svn: 238070
Instead of explicitly building constraints and adding them to our maps we
now use functions like map_order_le to add the relevant information to the
maps.
llvm-svn: 237934
Being here, we extend the interface to return the element type and not a pointer
to the element type. We also provide a function to get the size (in bytes) of
the elements stored in this array.
We currently still store the element size as an innermost dimension in
ScopArrayInfo, which is somehow inconsistent and should be addressed in future
patches.
llvm-svn: 237779
Besides a couple of interface cleanups, this change also contains a performance
optimization of isl_mat_product that should give us up to almost 6% compiletime
reduction.
llvm-svn: 237616
This code has been part of Polly's GPGPU backend, which has been remove together
with the code generation backend. Development now continues in an out-of-tree
branch.
llvm-svn: 237450
This reference ID is handy for use cases where we need to identify individual
memory accesses (e.g. to modify their access functions).
This is a reworked version of a patch originally developed by Yabin Hu as part
of his summer of code project.
llvm-svn: 237431
Modified two test cases to adjust to the above change in renaming.
These two files were causing the buildbot failure in Polly, #30204 for example.
Details in http://reviews.llvm.org/D9483
This checkin goes with r237150 and r237151
llvm-svn: 237203
Besides class, function and file names, we also change the command line option
from -polly-codegen-isl to just -polly-codegen. The isl postfix is a leftover
from the times when we still had the CLooG based -polly-codegen. Today it is
just redundant and we drop it.
llvm-svn: 237099
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 patch also changes the implementation of the ArrayInfoMap to a MapVector
which will ensure that iterating over the list of ArrayInfo objects gives
predictable results. The single loop that currently enumerates the ArrayInfo
objects only frees the individual objectes, hence a possibly changing
iteration order does not affect the outcome. The added robustness is for
future users of this interface.
llvm-svn: 236583
In the lnt benchmark MultiSource/Benchmarks/MallocBench/gs/gs with
scalar and PHI modeling we detected the multidimensional accesses
with sizes variant in the SCoP. This will check the sizes for validity.
llvm-svn: 236395
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
This will strip the constant factor of a parameter befor we add it to
the SCoP. As a result the access functions are simplified, e.g., for
the attached test case.
llvm-svn: 233501
When creating parameters the SCEVexpander may introduce new induction variables,
that possibly create scalar dependences in the original scop, before we code
generate the scop. The resulting scalar dependences may then inhibit correct
code generation of the scop. To prevent this, we first version the code without
a run-time check and only then introduce new parameters and the run-time
condition. The if-condition that guards the original scop from being modified by
the SCEVexpander.
This change causes some test case changes as the run-time conditions are now
introduced in the split basic block rather than in the entry basic block.
This fixes http://llvm.org/PR22069
Test case reduced by: Karthik Senthil
llvm-svn: 233477
This options was earlier used for experiments with the vectorizer, but to my
knowledge is not really used anymore. If anybody needs this, we can always
reintroduce this feature.
llvm-svn: 232934
Replacing the old band_tree based code with code that is based on the new
schedule tree [1] interface makes applying complex schedule transformations a lot
more straightforward. We now do not need to reason about the meaning of flat
schedules, but can use a more straightforward tree structure. We do not yet
exploit this a lot in the current code, but hopefully we will be able to do so
soon.
This change also allows us to drop some code, as isl now provides some higher
level interfaces to apply loop transformations such as tiling.
This change causes some small test case changes as isl uses a slightly different
way to perform loop tiling, but no significant functional changes are intended.
[1] http://impact.gforge.inria.fr/impact2014/papers/impact2014-verdoolaege.pdf
llvm-svn: 232911
These test cases did not verify the CHECK lines at all. We add the FileCheck
and also fix some broken CHECK lines. Being here, we extend the checks to
cover the whole loop structure.
llvm-svn: 232710
The BB vectorizer is deprecated and there is no point in generating code for it
any more. This option was introduced when there was not yet any loop vectorizer
in sight. Now being matured, Polly should target the loop vectorizer.
llvm-svn: 232099
This test case was supposed to test the range analysis but it became just
another delinearization test case after enabling delinearization.
Suggested-by: Johannes Doerfert
llvm-svn: 231599
When code generating array index expressions the types of the different
components of the index expressions may not always match. We extend the type of
the index expression (if possible) and assert otherwise.
llvm-svn: 231592
The performance test case just committed was the last open issue I was aware of.
We enable this by default to increase test coverage and to possibly trigger
reports of issues yet unknown.
llvm-svn: 231590
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
No test cases unfortunately as we do not yet generate isl_ast_op_and_then or
isl_ast_op_or_else. Those will be added in a later commit.
llvm-svn: 231268
If a scalar was defined and used only in a non-affine subregion we do
not need to model the accesses. However, if the scalar was defined
inside the region and escapes the region we have to model the access.
The same is true if the scalar was defined outside and used inside the
region.
llvm-svn: 230960
When we generate code for a whole region we have to respect dominance
and update it too.
The first is achieved with multiple "BBMap"s. Each copied block in the
region gets its own map. It is initialized only with values mapped in
the immediate dominator block, if this block is in the region and was
therefor already copied. This way no values defined in a block that
doesn't dominate the current one will be used.
To update dominance information we check if the immediate dominator of
the original block we want to copy is in the region. If so we set the
immediate dominator of the current block to the copy of the immediate
dominator of the original block.
llvm-svn: 230774
After a function was created we will verify it for Debug builds. If
errors are found and debug-type equals "polly-codegen-isl" the SCoP,
the isl AST, the function as well as the errors will be printed.
llvm-svn: 230767
isl recently introduced a new interface to create run-time checks from
constraint sets. Use this interface to simplify our run-time check generation.
llvm-svn: 230640
For Polly the two interesting changes are short_circuit && and || AST
expressions as well as the introduction of isl_ast_build_expr_from_set,
a well defined interface to compute ast expressions from constraint sets.
llvm-svn: 230636
With the patches r230325, r230329 and r230340 we can handle non-affine
control flow in (loop-free) subregions. As all LLVM test-suite tests pass and
we get ~20% more non-trivial SCoPs, we activate it now by default.
llvm-svn: 230624
This update contains:
- Fixes of minor issues detected by clang's scan_build
- More schedule tree infrastructure additions
This update slightly changes the output of our dependence analysis, but these
changes are purely syntactially.
llvm-svn: 230528
This is the code generation for region statements that are created
when non-affine control flow was present in the input. A new
generator, similar to the block or vector generator, for regions is
used to traverse and copy the region statement and to adjust the
control flow inside the new region in the end.
llvm-svn: 230340
This allows us to model non-affine regions in the SCoP representation.
SCoP statements can now describe either basic blocks or non-affine
regions. In the latter case all accesses in the region are accumulated
for the statement and write accesses, except in the entry, have to be
marked as may-write.
Differential Revision: http://reviews.llvm.org/D7846
llvm-svn: 230329
With this patch we allow the SCoP detection to detect regions as SCoPs
which have non-affine control flow inside. All non-affine regions are
tracked and later accessible to the ScopInfo.
As there is no real difference, non-affine branches as well as
floating point branches are covered (and both called non-affine
control flow). However, the detection is restricted to
overapproximate only loop free regions.
llvm-svn: 230325
Scops that only read seem generally uninteresting and scops that only write are
most likely initializations where there is also little to optimize. To not
waste compile time we bail early.
Differential Revision: http://reviews.llvm.org/D7735
llvm-svn: 229820
This is just a single commit that includes a performance optimization that
should improve dependence analysis time. Our performance bots should measure
this difference.
llvm-svn: 229476
This commit imports the latest isl version into lib/External/isl. The changes
relavant for Polly are:
1) Schedule trees [1] have been introduced as a more structured way to
describe schedules. Polly does not yet use them, but we may switch to them
in the near future.
2) Another set of coalescing changes [2] simplifies some data dependences and
removes a couple of code generation artifacts.
We now understand that the following sets can be merged:
{ Stmt_S1[i0, i1] -> Stmt_S2[i0 + i1] :
i0 >= 0 and i1 <= 1023 - i0 and i1 >= 1
Stmt_S1[i0, 0] -> Stmt_S2[i0] : i0 <= 1023 and i0 >= 1}
into:
{ Stmt_S1[i0, i1] -> Stmt_S2[i0 + i1] : i1 <= 1023 - i0 and i1 >= 0 and
i1 >= 1 - i0 and i0 >= 0 }
Changes of this kind reduce unnecessary specialization during code
generation.
- for (int c3 = 0; c3 <= 1023; c3 += 1) {
- if (c3 % 2 == 0) {
- Stmt_for_body3(c1, c3);
- } else
- Stmt_for_body3(c1, c3);
- }
+ for (int c3 = 0; c3 <= 1023; c3 += 1)
+ Stmt_for_body3(c1, c3);
[1] http://impact.gforge.inria.fr/impact2014/papers/impact2014-verdoolaege.pdf
[2] http://impact.gforge.inria.fr/impact2015/papers/impact2015-verdoolaege.pdf
llvm-svn: 229423
Alias checks might become costly if there are divisions that complicate the
description of the accessed locations. By overaproximating them we get fairly
accurate results without the huge compile time cost.
llvm-svn: 229252
namespace and header rather than the top-level header and using
declarations. These helpers impede modular builds and are going away.
Migrating away from them will also be necessary to start mixing in any
usage of the new pass manager.
llvm-svn: 229091
Without this change we get linker errors such as:
undefined reference to `llvm::dbgs()'
We only conditionally link in these libraries, as in BUILD_SHARED_LIBS=OFF mode,
linking in these libraries causes such functions (and especially global options)
to be defined twice. The "solution" I choose is most likely not ideal, but seems
to work. If any cmake specialist can suggest a better approach, this would be
appreciated.
We also drop a .c file that is not needed as it caused linker errors as well.
llvm-svn: 228914
This allows us to skip ast and code generation if we did not optimize
a SCoP and will not generate parallel or alias annotations. The
initial heuristic to exit is simple but allows improvements later on.
All failing test cases have been modified to disable early exit, thus
to keep their coverage.
Differential Revision: http://reviews.llvm.org/D7254
llvm-svn: 228851
These write are important as they will force the scheduling and code
generation of an otherwise trivial statement and also impose an order of
execution needed to guarantee the correct final value for a scalar in a loop.
Added test case modeled after ClamAV/clamscan.
llvm-svn: 228847
This change has two main purposes:
1) We do not use a static interface to hide an object we create and
destroy for every basic block we copy.
2) We allow the BlockGenerator to store information between calls to
the copyBB method. This will ease scalar/phi code generation
later on.
While a lot of method signatures were changed this should not cause
any real behaviour change.
Differential Revision: http://reviews.llvm.org/D7467
llvm-svn: 228443
This allows us to model PHI nodes in the polyhedral description
without demoting them. The modeling however will result in the
same accesses as the demotion would have introduced.
Differential Revision: http://reviews.llvm.org/D7415
llvm-svn: 228433
With this patch Polly is always GPL-free (no dependency on GMP any more). As a
result, building and distributing Polly will be easier. Furthermore, there is no
need to tightly coordinate isl and Polly releases anymore.
We import isl b3e0fa7a05d as well as imath 4d707e5ef2. These are the git
versions Polly currently was tested with when using utils/checkout_isl.sh. The
imported libraries are both MIT-style licensed.
We build isl and imath with -fvisibility=hidden to avoid clashes in case other
projects (such as gcc) use conflicting versions of isl. The use of imath can
temporarily reduce compile-time performance of Polly. We will work on
performance tuning in tree.
Patches to isl should be contributed first to the main isl repository and can
then later be reimported to Polly.
This patch is also a prerequisite for the upcoming isl C++ interface.
llvm-svn: 228193
The support is currently limited as we only allow them in the input but do
not emit them in the transformed SCoP due to the possible semantic changes.
Differential Revision: http://reviews.llvm.org/D5225
llvm-svn: 227054
lets 'ninja check-polly' pass for me with a lib64 build of LLVM.
I've not updated the standalone side as I don't use it and don't have an
easy way to test any changes I've made there. I mostly wanted to be able
to actually run Polly's tests when I update its use of LLVM's APIs
during my refactorings on the (very unlikely) off chance that I make
a change which compiles but does the wrong thing.
llvm-svn: 226420
This change ensures that the values that represent the array size of a
multi-dimensional access are correctly sign-extended when used to compute a
memory address used in the run-time alias check.
To make the test case more readable, we name the instructions that we generate.
llvm-svn: 225818
The max loop depth was incorrectly computed for scops that contain a
block from a loop but do not contain the entire loop. We need to
check that the full loop is contained in the region when computing
the max loop depth.
These scops occur when a region containing an inner loop is expanded
to include some blocks from the outer loop, but it cannot be fully
expanded to contain the outer loop because the region containing the
outer loop is invalid.
Differential Revision: http://reviews.llvm.org/D6913
llvm-svn: 225812
This support is still incomplete and consequently hidden behind a switch that
needs to be enabled. One problem is ATM that we incorrectly interpret very large
unsigned values as negative values even if used in an unsigned comparision.
llvm-svn: 225480
AF = dyn_cast<SCEVAddRecExpr>(Pair.second) may be NULL for some SCEVs that we do
not support. When reporting the error we still want to pass a pointer that is
known to always be non-NULL.
I do not yet have a test case for this, unfortunately.
llvm-svn: 225461
This would add another library dependency to Polly. In many cases the
JSCoP interface we have should be enough and an external JSCoP <> OpenSCoP
converter could be written. We can reconsider this if new use cases show up.
llvm-svn: 225390
We previously used a Twine here, but as pointed out by David Blaikie
and Mehdi Amini storing a temporary StringRef in a Twine is not a good
idea, as the StringRef will be freed before the Twine is used leaving
a Twine that points to uninitialized memory. We now make it explicit that
we use a StringRef here.
llvm-svn: 225342
We should reconsider this after having switched to imath (instead of gmp)
as the default isl backend, as this would allow us to keep a copy of isl
in the polly svn and to consequently make it easier to distribute Polly.
llvm-svn: 225262
Schedule dimensions that have the same constant value accross all statements do
not carry any information, but due to the increased dimensionality of the
schedule cost compile time. To not pay this cost, we remove constant dimensions
if possible.
llvm-svn: 225067
Without updating dependences we may lose implicit transitive dependences for
which all explicit dependences have gone through the statement iterations we
have just eliminated.
No test case. We should probably implement a -verify-dependences option.
This fixes llvm.org/PR21227
llvm-svn: 224459
The dead code elimination is a pass that looks very promising, but needs some
more compile-time tuning before enabling it by default seems sensible.
llvm-svn: 223965
This simplifies the construction of the input for the reduction dependence
computation and at the same time removes an assumption that expects the schedule
to be of 2D + 1 form (the odd dimensions giving textual order, the even
dimensions the loop iterations).
llvm-svn: 223621
Isl now specifically marks modulo operations that are compared against zero.
They can be implemented with the C/LLVM remainder operation.
We also update a couple of test cases where the output of isl has slightly
changed.
llvm-svn: 223607
This commit drops the Cloog support for Polly. The scripts and
documentation are changed to only use isl as prerequisity. In the code
all Cloog specific parts have been removed and all relevant tests have
been ported to the isl backend when it was created.
llvm-svn: 223141
Polly had a copy of this pass to create the canonical induction variables
necessary for the non-scev-based code generation. As we now always use SCEV
based code generation, canonical induction variables are not needed any more.
llvm-svn: 222979
SCEV based code generation has been the default for two weeks after having
been tested for a long time. We now drop the support the non-scev-based code
generation.
llvm-svn: 222978
This fixes LINK_POLLY_INTO_TOOLS=ON builds, which previously failed with:
CMake Error: install(EXPORT "LLVMExports" ...) includes target "opt" which
requires target "Polly" that is not in the export set.
CMake Error: install(EXPORT "LLVMExports" ...) includes target "bugpoint" which
requires target "Polly" that is not in the export set.
llvm-svn: 222977
In TempScopInfo::buildCondition we extract the conditions to guard the
BB *in addition of* loop bounds. This means we should only consider the
conditions in the paths (in CFG) that do not contain cycles (loops).
At the same time, we set the invert flag if the FalseBB of the current
branch dominates our target BB to indicate that we reach the target BB
with an inverted condition from the current branch.
In this case, the path from the FalseBB contains a cycle if the FalseBB
is the target of a backedge. The conditions implied by such a path should
not be consider. We can identify such a case by checking if the TrueBB
also dominates our target BB, which means we can also reach our target
BB from the TrueBB, without going through the backedge.
llvm-svn: 222907
In case a GEP instruction references into a fixed size array e.g., an access
A[i][j] into an array A[100x100], LLVM-IR does not guarantee that the subscripts
always compute values that are within array bounds. We now derive the set of
parameter values for which all accesses are within bounds and add the assumption
that the scop is only every executed with this set of parameter values.
Example:
void foo(float A[][20], long n, long m {
for (long i = 0; i < n; i++)
for (long j = 0; j < m; j++)
A[i][j] = ...
This loop yields out-of-bound accesses if m is at least 20 and at the same time
at least one iteration of the outer loop is executed. Hence, we assume:
n <= 0 or m <= 20.
Doing so simplifies the dependence analysis problem, allows us to perform
more optimizations and generate better code.
TODO: The location where the GEP instruction is executed is not necessarily the
location where the memory is actually accessed. As a result scanning for GEP[s]
is imprecise. Even though this is not a correctness problem, this imprecision
may result in missed optimizations or non-optimal run-time checks.
In polybench where this mismatch between parametric loop bounds and fixed size
arrays is common, we see with this patch significant reductions in compile time
(up to 50%) and execution time (up to 70%). We see two significant compile time
regressions (fdtd-2d, jacobi-2d-imper), and one execution time regression
(trmm). Both regressions arise due to additional optimizations that have been
enabled by this patch. They can be addressed in subsequent commits.
http://reviews.llvm.org/D6369
llvm-svn: 222754
SCEV based code generation allows Polly to detect and generate code for loops
that do not have an explicit induction variable, but only virtual induction
variables given by SCEV.
Being able to do so has two main benefits:
- We can detect more scops by default
- We require less canonicalization before Polly, which means we get closer
to our goal of not touching the IR before analyzing its properties.
Specifically, we do not need to run -polly-indvars to introduce explicit
canonical induction variables.
This switch became possible as both the isl code generation and -polly-parallel
are LNT error free with SCEV based code generation and the isl ast generator.
llvm-svn: 222113
This patch includes tests where we actually need to adjust the CHECK lines
for SCEV based code generation. Besides these adjustments we add explicit
calls to -polly-codegen-scev=[true|false] and make sure we test both cases.
llvm-svn: 222112
Johannes Doerfert