Certain backends, e.g. NVPTX, do not support '.' in function names. Hence,
we ensure all '.' are replaced by '_' when generating function names for
subfunctions. For the current OpenMP code generation, this is not strictly
necessary, but future uses cases (e.g. GPU offloading) need this issue to be
fixed.
llvm-svn: 246980
Our alias metadata is currently not emitted in a deterministic order. As it
is not needed in this test, we just drop it for now (but keep in mind to fix
this).
llvm-svn: 246942
When this option is enabled, Polly will emit printf calls for each scalar
load/and store which dump the scalar value loaded/stored at run time.
This patch also refactors the RuntimeDebugBuilder to use variadic templates
when generating CPU printfs. As result, it now becomes easier to print
strings that consist of a set of arguments. Also, as a single printf
call is emitted, it is more likely for such strings to be emitted atomically
if executed multi-threaded.
llvm-svn: 246941
Some of the structures are renamed, subfunction introduced to clarify the
individual steps and comments are added describing their functionality.
llvm-svn: 246929
In the common case, the access functions are not modified, hence there is no
need to obtain the IslAstBuild context at all. This should not only be minimally
faster, but this also allows the IslNodeBuilder to work on asts that are not
annotated with isl_ast_builds as long as the memory accesses are not modified.
llvm-svn: 246928
By inspection the update of the GlobalMaps in the RegionGenerator seems unneed,
and is removed as also no test cases fail when dropping this. Johannes Doerfert
confirmed that this is indeed save:
"I think that code was needed when we did not use the scalar codegen by default.
Now everything defined in a non-affine region should be communicated via memory
and reloaded in the user block. Hence, we should be good removing this code."
llvm-svn: 246926
When computing the index expressions for new, multi-dimensional memory accesses
these new index expressions may reference original llvm::Values that are not
transfered into the OpenMP subfunction. Using GlobalMap we now replace
references to such values with the rewritten values that have e.g. been passed
to the OpenMP subfunction.
llvm-svn: 246923
The GlobalMap variable used in BlockGenerator should always reference the same
list througout the entire code generation, hence we can make it a member
variable to avoid passing it around through every function call.
History: Before we switched to the SCEV based code generation the GlobalMap
also contained a mapping form old to new induction variables, hence it was
different for each ScopStmt, which is why we passed it as function argument
to copyStmt. The new SCEV based code generation now uses a separate mapping
called LTS -> LoopToSCEV that maps each original loop to a new loop iteration
variable provided as a SCEVExpr. The GlobalMap is currently mostly used for
OpenMP code generation, where references to parameters in the original function
need to be rewritten to the locations of these variables after they have been
passed to the subfunction.
Suggested-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 246920
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
By just removing dimensions (and the constraints they are involved in) we
may loose information about the dimensions we do not remove. By instead
using project_out, we are sure all constraints on the outer dimensions are
preserved.
No test case, as this error condition is very unlikely to be triggered by
isl's current code. We still 'fix' this, as isl gives little guarantees
regarding the behavior of remove_divs.
llvm-svn: 246567
This case probably does not happen for LLVM generated code that is in loop
simplify form, but Polly does support such kind of loops. This commit ensures we
have test coverage as well.
llvm-svn: 246543
Code generation currently does not expect unbounded loops. When
using ISL to compute the loop trip count, if we find that the
iteration domain remains unbounded, we invalidate the Scop by
creating an infeasible context.
Contributed-by: Matthew Simpson <mssimpso@codeaurora.org>
This fixes PR24634.
Differential Revision: http://reviews.llvm.org/D12493
llvm-svn: 246477
Instead of building domains with MaxLoopDepth dimensions, we now build
the domains such that they have the right amount of dimensions all the
time.
llvm-svn: 246443
Before this commit we did this only for Arguments or Constants, but indeed
an instruction may define a value a lot higher up in the dominance tree, but
the actual write generally needs to happen right before branching to the
PHI node. Otherwise, the writes of different branches into PHI nodes may get
intermixed if they lay higher up in the dominance tree.
llvm-svn: 246441
There is no reason the loops in a region need to touch either entry or exit
block. Hence, we need to look through all loops that may touch the region as
well as their children to understand if our region has at least two loops.
llvm-svn: 246433
While ignoring read-only scalar dependences it was not necessary to consider
store instructins, but as store instructions can be the target of a scalar
read-only dependency we need to consider them for the construction of scalar
read-only dependences.
llvm-svn: 246429
Our OpenMP code generation generated part of its launching code directly into
the start basic block and without this change the scalar initialization was
run _after_ the OpenMP threads have been launched. This resulted in
uninitialized scalar values to be used.
llvm-svn: 246427
Even though these are not strictly necessary for sequential code generation,
we still model both for sequential and parallel code generation to reduce
the set of configurations that needs to be tested. If this turns out, against
what we currently see, to be significant overhead, we can decide to limit this
feature again to parallel code-generation use cases only.
llvm-svn: 246420
Scalar dependences between scop statements have caused troubles during parallel
code generation as we did not pass on the new stack allocation created for such
scalars to the parallel subfunctions. This change now detects all scalar
reads/writes in parallel subfunctions, creates the allocas for these scalar
objects, passes the resulting memory locations to the subfunctions and ensures
that within the subfunction requests for these memory locations will return the
rewritten values.
Johannes suggested as a future optimization to privatizing some of the scalars
in the subfunction.
llvm-svn: 246414
In order to compute domain conditions for conditionals we will now
traverse the region in the ScopInfo once and build the domains for
each block in the region. The SCoP statements can then use these
constraints when they build their domain.
The reason behind this change is twofold:
1) This removes a big chunk of preprocessing logic from the
TempScopInfo, namely the Conditionals we used to build there.
Additionally to moving this logic it is also simplified. Instead
of walking the dominance tree up for each basic block in the
region (as we did before), we now traverse the region only
once in order to collect the domain conditions.
2) This is the first step towards the isl based domain creation.
The second step will traverse the region similar to this step,
however it will propagate back edge conditions. Once both are in
place this conditional handling will allow multiple exit loops
additional logic.
Reviewers: grosser
Differential Revision: http://reviews.llvm.org/D12428
llvm-svn: 246398
We already modeled read-only dependences to scalar values defined outside the
scop as memory reads and also generated read accesses from the corresponding
alloca instructions that have been used to pass these scalar values around
during code generation. However, besides for PHI nodes that have already been
handled, we failed to store the orignal read-only scalar values into these
alloc. This commit extends the initialization of scalar values to all read-only
scalar values used within the scop.
llvm-svn: 246394
The current code really tries hard to use getNewScalarValue(), which checks if
not the original value, but a possible copy or demoted value needs to be stored.
In this calling context it seems, that we _always_ use the ScalarValue that
comes from the incoming PHI node, but never any other value. As also no test
cases fail, it seems right to just drop this call to getNewScalarValue and
remove the parameters that are not needed any more.
Johannes suggested that code like this might be needed for parallel code
generation with offloading, but it was still unclear if/what exactly would
be needed. As the parallel code generation does currently not support scalars
at all, we will remove this code for now and add relevant code back when
complitng the support of scalars in the parallel code generation.
Reviewers: jdoerfert
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D12470
llvm-svn: 246389
Our code generation currently does not support scalar references to metadata
values. Hence, it would crash if we try to model scalar dependences to metadata
values. Fortunately, for one of the common uses, debug information, we can
for now just ignore the relevant intrinsics and consequently the issue of how
to model scalar dependences to metadata.
llvm-svn: 246388
This commit drops some dead code. Specifically, there is no need to initialize
the virtual memory locations of scalars in BlockGenerator::handleOutsideUsers,
the function that initalizes the escape map that keeps track of out-of-scope
uses of scalar values. We already model instructions inside the scop that
are used outside the scope (escaping instructions) as scalar memory writes at
the position of the instruction. As a result, the virtual memory location of
this instructions is already initialized when code-generating the corresponding
virtual scalar write and consequently does not need to be initialized later on
when generating the set of escaping values.
Code references:
In TempScopInfo::buildScalarDependences we detect scalar cross-statement
dependences for all instructions (including PHIs) that have uses outside of the
scop's region:
// Check whether or not the use is in the SCoP.
if (!R->contains(UseParent)) {
AnyCrossStmtUse = true;
continue;
}
We use this information in TempScopInfo::buildAccessFunctions were we build
scalar write memory accesses for all these instructions:
if (!isa<StoreInst>(Inst) &&
buildScalarDependences(Inst, &R, NonAffineSubRegion)) {
// If the Instruction is used outside the statement, we need to build the
// write access.
IRAccess ScalarAccess(IRAccess::MUST_WRITE, Inst, ZeroOffset, 1, true,
Inst);
Functions.push_back(std::make_pair(ScalarAccess, Inst));
}
Reviewers: jdoerfert
Subscribers: pollydev, llvm-commits
Differential Revision: http://reviews.llvm.org/D12472
llvm-svn: 246383
I ran the script from r246327 and it touched all the right files;
committing now to hopefully right the bots, but if my check-polly
doesn't come back clean I'll keep looking.
http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/33648
llvm-svn: 246341
For external users, the memory locations into which we generate scalar values
may be of interest. This change introduces two functions that allow to obtain
(or create) the AllocInsts for a given BasePointer.
We use this change to simplify the code in BlockGenerators.
llvm-svn: 246285
This allows users to extend the IslNodeBuilder to create their own optimization
passes. This feature is not used in Polly's codebase itself, but as these
funtions are not performance critical, the cost of making experiments of
external users easier seems low enough to do so.
llvm-svn: 246281
If a region does not have more than one loop, we do not identify it as
a Scop in ScopDetection. The main optimizations Polly is currently performing
(tiling, preparation for outer-loop vectorization and loop fusion) are unlikely
to have a positive impact on individual loops. In some cases, Polly's run-time
alias checks or conditional hoisting may still have a positive impact, but those
are mostly enabling transformations which LLVM already performs for individual
loops. As we do not focus on individual loops, we leave them untouched to not
introduce compile time regressions and execution time noise. This results in
good compile time reduction (oourafft: -73.99%, smg2000: -56.25%).
Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in>
Reviewers: grosser
Differential Revision: http://reviews.llvm.org/D12268
llvm-svn: 246161
This change allows the BlockGenerator to be reused in contexts where we want to
provide different/modified isl_ast_expressions, which are not only changed to
a different access relation than the original statement, but which may indeed
be different for each code-generated instance of the statement.
We ensure testing of this feature by moving Polly's support to import changed
access functions through a jscop file to use the BlockGenerators support for
generating arbitary access functions if provided.
This commit should not change the behavior of Polly for now. The diff is rather
large, but most changes are due to us passing the NewAccesses hash table through
functions. This style, even though rather verbose, matches what is done
throughout the BlockGenerator with other per-statement properties.
llvm-svn: 246144
Use ISL to compute the loop trip count when scalar evolution is unable to do
so.
Contributed-by: Matthew Simpson <mssimpso@codeaurora.org>
Differential Revision: http://reviews.llvm.org/D9444
llvm-svn: 246142
Other passes which perform different optimizations might be interested in
also applying data-locality transformations as part of their overall
transformation.
llvm-svn: 245824
Originally, we intersected the iteration space with the AssumedContext before
computing the minimal/maximal memory offset in our run-time alias checks. With
this patch we drop this intersection as the AssumedContext can - for larger or
more complex scops - become very complicated (contain many disjuncts). When
intersecting an object with many disjuncts with other objects, the number of
disjuncts in these other objects also increases quickly. As a result, the
compile time is unnecessarily increased. This patch now drops the intersection
with the assumed context to ensure we do not pay unnecessary compile time
costs.
With this patch we see -3.17% reduction in compile time for 3mm with default
flags and -17.87% when compiling 3mm with -DPOLYBENCH_USE_C99_PROTO flag. We
did not observe any regressions in LNT.
Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in>
Reviewers: grosser
Differential Revision: http://reviews.llvm.org/D12198
llvm-svn: 245617
To avoid multiple exits and the resulting complicated conditions when
creating a SCoP we now use the single hasFeasibleRuntimeContext()
check to decide if a SCoP should be dismissed right after
construction. If building runtime checks failed the assumed context is
made infeasible, hence the optimized version will never be executed
and the SCoP can be dismissed.
llvm-svn: 245593
If nothing is executed we can bail out early. Otherwise we can use the
constraints that ensure at least one statement is executed for
simplification.
llvm-svn: 245585
We will record if a SAI is the base of another SAI or derived from it.
This will allow to reason about indirect base pointers later on and
allows a clearer picture of indirection also in the SCoP dump.
llvm-svn: 245584
Register tiling in Polly is for now just an additional level of tiling which
is fully unrolled. It is disabled by default. To make this useful for more than
experiments, we still need a cost function as well as possibly further
optimizations that teach LLVM to actually put some of the values we got into
scalar registers.
llvm-svn: 245564
By default we only use one level of tiling for loops, but in general tiling
for multiple levels is trivial for us. Hence, we add a set of options that
allow people to play with a second level of tiling. If this is profitable for
some cases we can work on heuristics that allow us to identify these cases
and use two-level tiling for them.
llvm-svn: 245563
Instead of generating code for an empty assumed context we bail out
early. As the number of assumptions we generate increases this becomes
more and more important. Additionally, this change will allow us to
hide internal contexts that are only used in runtime checks e.g., a
boundary context with constraints not suited for simplifications.
llvm-svn: 245540
To make alias scope metadata generation work in OpenMP mode we now provide
the ScopAnnotator with information about the base pointer rewrite that happens
when passing arrays into the OpenMP subfunction.
llvm-svn: 245451
Polly uses 'prevectorization' to enable outer loop vectorization. When
vectorizing an outer loop, we strip-mine <number-of-prevec-dims> loop
iterations which are than interchanged to the innermost level such that LLVM's
inner loop vectorizer (or Polly's simple vectorizer) can easily vectorize this
loop. The number of loop iterations to strip-mine is now configurable with the
option -polly-prevect-width=<number-of-prevec-dims>.
This is mostly a debugging option. We should probably add a heuristic that
derives the number of prevectorization dimensions from the target data and
the data types used.
llvm-svn: 245424
This test was written to check the workings of IndependentBlocks on
arrays which doesn't do such transformations anymore. The test itself
is still useful to check that the region is rejected as SCoP.
llvm-svn: 245353
This patch changes Polly to compute the data-dependences on the schedule tree
instead of a flat schedule representation. Calculating dependences directly on
the schedule tree results in some good compile-time improvements (adi : -23.35%,
3mm : -9.57%), as the structure of the schedule can be exploited for increased
efficiency.
Earlier experiments with schedule tree based dependence analysis in Polly showed
some compile-time regressions. These regressions arose due to the schedule tree
based dependence analysis not taking into account the domain constraints of the
schedule tree. As a result, the computed dependences were different and this
difference caused in some cases the schedule optimizer to take a very long time.
Since isl version fe865996 the schedule tree based dependence analysis takes
domain constraints into account, which fixes the earlier compile-time issues.
Contributed-by: Pratik Bhatu <cs12b1010@iith.ac.in>
llvm-svn: 245300
executeScopConditionally would destroy a predecessor region if it the
scop's entry was the region's exit block by forking it to polly.start
and thus creating a secnd exit out of the region. This patch "shrinks"
the predecessor region s.t. polly.split_new_and_old is not the
region's exit anymore.
llvm-svn: 245294
The SCEVExpander cannot deal with all SCEVs Polly allows in all kinds
of expressions. To this end we introduce a ScopExpander that handles
the additional expressions separatly and falls back to the
SCEVExpander for everything else.
Reviewers: grosser, Meinersbur
Subscribers: #polly
Differential Revision: http://reviews.llvm.org/D12066
llvm-svn: 245288
The new field in the MemoryAccess allows us to track a value related
to that access:
- For real memory accesses the value is the loaded result or the
stored value.
- For straigt line scalar accesses it is the access instruction
itself.
- For PHI operand accesses it is the operand value.
We use this value to simplify code which deduced information about the value
later in the Polly pipeline and was known to be error prone.
Reviewers: grosser, Meinsersbur
Subscribers: #polly
Differential Revision: http://reviews.llvm.org/D12062
llvm-svn: 245213
This allows the code generation to continue working even if a needed
value (that is reloaded anyway) was not yet demoted. Instead of
failing it will now create the location for future demotion to memory
and load from that location. The stores will use the same location and
by construction execute before the load even if the textual order in
the generated AST is otherwise.
Reviewers: grosser, Meinersbur
Subscribers: #polly
Differential Revision: http://reviews.llvm.org/D12072
llvm-svn: 245203
This test case crashes the scalar code generation as we are not
consistent with the usage of the assumed context. To be precise, we
use the assumed context for the dependence analysis but not to
restrict the domains of the statements.
A step by step explanation of the problem is given in the test case.
llvm-svn: 245176
This option allows the user to provide additional information about parameter
values as an isl_set. To specify that N has the value 1024, we can provide
the context -polly-context='[N] -> {: N = 1024}'.
llvm-svn: 245175
The July issue of TOPLAS contains a 50 page discussion of the AST generation
techniques used in Polly. This discussion gives not only an in-depth
description of how we (re)generate an imperative AST from our polyhedral based
mathematical program description, but also gives interesting insights about:
- Schedule trees: A tree-based mathematical program description that enables us
to perform loop transformations on an abstract level, while issues like the
generation of the correct loop structure and loop bounds will be taken care of
by our AST generator.
- Polyhedral unrolling: We discuss techniques that allow the unrolling of
non-trivial loops in the context of parameteric loop bounds, complex tile
shapes and conditionally executed statements. Such unrolling support enables
the generation of predicated code e.g. in the context of GPGPU computing.
- Isolation for full/partial tile separation: We discuss native support for
handling full/partial tile separation and -- in general -- native support for
isolation of boundary cases to enable smooth code generation for core
computations.
- AST generation with modulo constraints: We discuss how modulo mappings are
lowered to efficient C/LLVM code.
- User-defined constraint sets for run-time checks We discuss how arbitrary
sets of constraints can be used to automatically create run-time checks that
ensure a set of constrainst actually hold. This feature is very useful to
verify at run-time various assumptions that have been taken program
optimization.
Polyhedral AST generation is more than scanning polyhedra
Tobias Grosser, Sven Verdoolaege, Albert Cohen
ACM Transations on Programming Languages and Systems (TOPLAS), 37(4), July 2015
llvm-svn: 245157
This modifies the order in which Polly passes are executed.
Assuming a function has two scops (A and B), the order before was:
FunctionPassManager
ScopDetection
IndependentBlocks
TempScopInfo for A and B
RegionPassManager
ScopInfo for A
DependenceInfo for A
IslScheduleOptimizer for A
IslAstInfo for A
CodeGeneration for A
ScopInfo for B
DependenceInfo for B
IslScheduleOptimizer for B
IslAstInfo for B
CodeGeneration for B
After this patch:
FunctionPassManager
ScopDetection
IndependentBlocks
RegionPassManager
TempScopInfo for A
ScopInfo for A
DependenceInfo for A
IslScheduleOptimizer for A
IslAstInfo for A
CodeGeneration for A
TempScopInfo for B
ScopInfo for B
DependenceInfo for B
IslScheduleOptimizer for B
IslAstInfo for B
CodeGeneration for B
TempScopInfo for B might store information and references to the IR
that CodeGeneration for A might modify. Changing the order ensures that
the IR is not modified from the analysis of a region until code
generation.
Reviewers: grosser
Differential Revision: http://reviews.llvm.org/D12014
llvm-svn: 245091
This change extends the BlockGenerator to not only allow Instructions as
base elements of scalar dependences, but any llvm::Value. This allows
us to code-generate scalar dependences which reference function arguments, as
they arise when moddeling read-only scalar dependences.
llvm-svn: 244874
While the compile time is not affected by this patch much it will
allow us to look at all translated expressions after the SCoP is build
in a convenient way. Additionally, bigger SCoPs or SCoPs with
repeating complicated expressions might benefit from the cache later
on.
Reviewers: grosser, Meinersbur
Subscribers: #polly
Differential Revision: http://reviews.llvm.org/D11975
llvm-svn: 244734
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
Tobias Grosser