Hoist runtime checks in the loop nest if they guard an "error" like event.
Such events are recognized as blocks with an unreachable terminator or a call
to the ubsan function that deals with out of bound accesses. Other "error"
events can be added easily.
We will ignore these blocks when we detect/model/optmize and code generate SCoPs
but we will make sure that they would not have been executed using the assumption
framework.
llvm-svn: 247310
As we do not rely on ScalarEvolution any more we do not need to get
the backedge taken count. Additionally, our domain generation handles
everything that is affine and has one latch and our ScopDetection will
over-approximate everything else.
This change will therefor allow loops with:
- one latch
- exiting conditions that are affine
Additionally, it will not check for structured control flow anymore.
Hence, loops and conditionals are not necessarily single entry single
exit regions any more.
Differential Version: http://reviews.llvm.org/D12758
llvm-svn: 247289
The TempScopInfo (-polly-analyze-ir) pass is removed and its work taken
over by ScopInfo (-polly-scops). Several tests depend on
-polly-analyze-ir and use -polly-scops instead which for the moment
prints the output of both passes. This again is not expected by some
other tests, especially those with negative searches, which have been
adapted.
Differential Version: http://reviews.llvm.org/D12694
llvm-svn: 247288
This patch replaces the last legacy part of the domain generation, namely the
ScalarEvolution part that was used to obtain loop bounds. We now iterate over
the loops in the region and propagate the back edge condition to the header
blocks. Afterwards we propagate the new information once through the whole
region. In this process we simply ignore unbounded parts of the domain and
thereby assume the absence of infinite loops.
+ This patch already identified a couple of broken unit tests we had for
years.
+ We allow more loops already and the step to multiple exit and multiple back
edges is minimal.
+ It allows to model the overflow checks properly as we actually visit
every block in the SCoP and know where which condition is evaluated.
- It is currently not compatible with modulo constraints in the
domain.
Differential Revision: http://reviews.llvm.org/D12499
llvm-svn: 247279
The support for modulo expressions is not comlete and makes the new
domain generation harder. As the currently broken domain generation
needs to be replaced, we will first swap in the new, fixed domain
generation and make it compatible with the modulo expressions later.
llvm-svn: 247278
This prepares for a series of patches that merges TempScopInfo into ScopInfo to
reduce Polly's code complexity. Only ScopInfo.{cpp|h} will be left thereafter.
Moving the code of TempScopInfo in one commit makes the mains diffs simpler to
understand.
In detail, merging the following classes is planned:
TempScopInfo into ScopInfo
TempScop into Scop
IRAccess into MemoryAccess
Only moving code, no functional changes intended.
Differential Version: http://reviews.llvm.org/D12693
llvm-svn: 247274
The support for pointer expressions is broken as it can only handle
some patterns in the IslExprBuilder. We should to treat pointers in
expressions the same as integers at some point and revert this patch.
llvm-svn: 247147
Add a custom makefile rule to generate lib/External/isl/gitversion.h
from GIT_HEAD_ID and trigger it using BULIT_SOURCES to ensure the file
exists before compilation starts.
The latest ISL creates gitversion.h from Makefile.am only, instead also
from configure.ac in previous version. While the Polly build invokes
configure, it does not invoke ISL's make such that the file was missing.
Invoking ISL's make would come with additional problems such as
triggering automake because of not preserved file time stamps.
Re-running automake might not be successful on other system
configurations for instance because it was preconfigured without
--with-clang option.
llvm-svn: 247142
Not all users of our IslNodeBuilder will attach scheduling information to the
AST in the same way IslAstInfo is doing it today. By going through a virtual
function when extracting the schedule of an AST node other users can provide
their own functions for extract scheduling information in case they attach
scheduling information in a different way to the AST nodes.
No functional change for Polly itself intended.
llvm-svn: 247126
While we do not need to model PHI nodes in the region exit (as it is not part
of the SCoP), we need to prepare for the case that the exit block is split in
code generation to create a single exiting block. If this will happen, hence
if the region did not have a single exiting block before, we will model the
operands of the PHI nodes as escaping scalars in the SCoP.
Differential Revision: http://reviews.llvm.org/D12051
llvm-svn: 247078
Instead of having two separate options
-polly-detect-scops-in-functions-without-loops and
-polly-detect-scops-in-regions-without-loops we now just use
-polly-detect-unprofitable to force the detection of scops ignoring any compile
time saving bailout heuristics.
llvm-svn: 247057
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
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
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
Sylvestre Ledru