It seems we added guards to check for non-existing std::map elements to make
sure they are default constructed before first accessed. Besides, the code
being wrong because of checking Context.NonAffineAccesses[BasePointer].size()
instead of Context.cound(BasePointer), such a check is also not necessary
as std::map takes care of this already.
From the std::map documentation:
"If k does not match the key of any element in the container, the function
inserts a new element with that key and returns a reference to its mapped value.
Notice that this always increases the container size by one, even if no mapped
value is assigned to the element (the element is constructed using its default
constructor)."
llvm-svn: 217506
Arcanist (arc) will now always run linters before uploading any new
commit to Phabricator. All errors/warnings (or their absence) will be
shown in the web interface together with a explanation by the commiter
(arcanist will ask the commiter if the build was not clean).
The linters include:
- clang-format
- spelling check
- permissions check (aka. chmod)
- filename check
- merge conflict marker check
Note, that their scope is sometimes limited (see .arclint for
details).
This commit also fixes all errors and warnings these linters reported,
namely:
- spelling mistakes and typos
- executable permissions for various text files
Differential Revision: http://reviews.llvm.org/D4916
llvm-svn: 215871
This will spill out information about LLVM-internals. However, in cases
where the name of the Value matches the name of the array in the source,
we provide more useful information. In cases where we spill internals,
the information still might help the user to pin down the correct
arrays.
The problem we face here is: The error is pinned to the debug location
of one of the offending values out of the alias set instead of all of them.
The more information we give the user about the set of aliasing
pointers the better.
llvm-svn: 215830
This reverts commit 215684. The intention of the commit is great, but
unfortunately it seems to be the cause of 14 LNT test suite failures:
http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly/builds/116
To make our buildbots and performance testers green until this issue is solved,
we temporarily revert this commit.
llvm-svn: 215816
The support is limited to signed modulo access and condition
expressions with a constant right hand side, e.g., A[i % 2] or
A[i % 9]. Test cases are modified according to this new feature and
new test cases are added.
Differential Revision: http://reviews.llvm.org/D4843
llvm-svn: 215684
Store the llvm::Value pointers of the AliasSet instead of the AliasSet
itself.
We have to be careful about changed IR when the message is generated,
because the Value pointers might not exist anymore. This would render
the Diagnostic invalid. For now we just assert there.
Simply do not retreive a diagnostic message after the IR has changed
it's not valid information anyway.
llvm-svn: 215625
There is no needed for neither 1-dimensional nor higher dimensional arrays to
require positive offsets in the outermost array dimension.
We originally introduced this assumption with the support for delinearizing
multi-dimensional arrays.
llvm-svn: 214665
+ Split all reduction dependences and map them to the causing memory accesses.
+ Print the types & base addresses of broken reductions for each "reduction
parallel" marked loop (OpenMP style).
+ 3 test cases to show how reductions are now represented in the isl ast.
The mapping "(ast) loops -> broken reductions" is also needed to find the
memory accesses we need to privatize in a loop.
llvm-svn: 214489
+ Introduced dependency type TYPE_TC_RED to represent the transitive closure
(& the reverse) of reduction dependences. These are used when we check for
reduction parallel loops.
+ Test cases including loop reversals and modulo schedules which compute
reductions in a alternated order.
llvm-svn: 213019
As our delinearization works optimistically, we need in some cases run-time
checks that verify our optimistic assumptions. A simple example is the
following code:
void foo(long n, long m, long o, double A[n][m][o]) {
for (long i = 0; i < 100; i++)
for (long j = 0; j < 150; j++)
for (long k = 0; k < 200; k++)
A[i][j][k] = 1.0;
}
After clang linearized the access to A and we delinearized it again to
A[i][j][k] we need to ensure that we do not access the delinearized array
out of bounds (this information is not available in LLVM-IR). Hence, we
need to verify the following constraints at run-time:
CHECK: Assumed Context:
CHECK: [o, m] -> { : m >= 150 and o >= 200 }
llvm-svn: 212198
This change is particularly useful in the code generation as we need
to know which binary operator/identity element we need to combine/initialize
the privatization locations.
+ Print the reduction type for each memory access
+ Adjusted the test cases to comply with the new output format and
to test for the right reduction type
llvm-svn: 212126
Iterate over all store memory accesses and check for valid binary reduction
candidate loads by following the operands of the stored value. For each
candidate pair we check if they have the same base address and there are no
other accesses which may overlap with them. This ensures that no intermediate
value can escape into other memory locations or is overwritten at some point.
+ 17 test cases for reduction detection and reduction dependency modeling
llvm-svn: 211957
Enabling -keep-going in ScopDetection causes expansion to an invalid
Scop candidate.
Region A <- Valid candidate
|
Region B <- Invalid candidate
If -keep-going is enabled, ScopDetection would expand A to A+B because
the RejectLog is never checked for errors during expansion.
With this patch only A becomes a valid Scop.
llvm-svn: 211875
This change will ease the transision to multiple reductions per statement as
we can now distinguish the effects of multiple reductions in the same
statement.
+ Wrapped reduction dependences are used to compute privatization dependences
+ Modified test cases to account for the change
llvm-svn: 211795
This dependency analysis will keep track of memory accesses if they might be
part of a reduction. If not, the dependences are tracked on a statement level.
The main reason to do this is to reduce the compile time while beeing able to
distinguish the effects of reduction and non-reduction accesses.
+ Adjusted two test cases
llvm-svn: 211794
Use a container class to store the reject logs. Delegating most calls to
the internal std::map and add a few convenient shortcuts (e.g.,
hasErrors()).
llvm-svn: 211780
Add support for generating optimization remarks after completing the
detection of Scops.
The goal is to provide end-users with useful hints about opportunities that
help to increase the size of the detected Scops in their code.
By default the remark is unspecified and the debug location is empty. Future
patches have to expand on the messages generated.
This patch brings a simple test case for ReportFuncCall to demonstrate the
feature.
Reports all missed opportunities to increase the size/number of valid
Scops:
clang <...> -Rpass-missed="polly-detect" <...>
opt <...> -pass-remarks-missed="polly-detect" <...>
Reports beginning and end of all valid Scops:
clang <...> -Rpass="polly-detect" <...>
opt <...> -pass-remarks="polly-detect" <...>
Differential Revision: http://reviews.llvm.org/D4171
llvm-svn: 211769
+ Collect reduction dependences
+ Introduced TYPE_RED in Dependences.h which can be used to obtain the
reduction dependences
+ Used TYPE_RED to prevent parallelization while we do not have a privatizing
code generation
+ Relax the dependences for non-parallel code generation
+ Add privatization dependences to ensure correctness
+ 12 Test cases to check for reduction and privatization dependences
llvm-svn: 211369
+ Flag to indicate reduction like statements
+ Command line option to (dis)allow multiplicative reduction opcodes
+ Two simple positive test cases, one fp test case w and w/o fast math
+ One "negative" test case (only reduction like but no reduction)
llvm-svn: 211114
+ Added const iterator version
+ Changed name to begin/end to allow range loops
+ Changed call sites to range loops
+ Changed typename to (const_)iterator
llvm-svn: 210927
Fixes#19976.
The error log does not contain an error, in case we reject a candidate
without generating a diagnostic message by using invalid<>(...). This is
the case for the top-level region of a function.
The patch comes without a test-case because adding a useful one requires
additional code just for triggering it. Before the patch it would only trigger,
if we try to print the CFG with Scop error annotations.
llvm-svn: 210753
Without this patch, the testcase would fail on the delinearization of the second
array:
; void foo(long n, long m, long o, double A[n][m][o]) {
; for (long i = 0; i < n; i++)
; for (long j = 0; j < m; j++)
; for (long k = 0; k < o; k++) {
; A[i+3][j-4][k+7] = 1.0;
; A[i][0][k] = 2.0;
; }
; }
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[3 + i0, -4 + i1, 7 + i2] };
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
Here is the output of FileCheck on the testcase without this patch:
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
^
<stdin>:26:2: note: possible intended match here
[n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[o0] };
^
It is possible to find a good delinearization for A[i][0][k] only in the context
of the delinearization of both array accesses.
There are two ways to delinearize together all array subscripts touching the
same base address: either duplicate the code from scop detection to first gather
all array references and then run the delinearization; or as implemented in this
patch, use the same delinearization info that we computed during scop detection.
llvm-svn: 210117
Instead of relying on the delinearization to infer the size of an element,
compute the element size from the base address type. This is a much more precise
way of computing the element size than before, as we would have mixed together
the size of an element with the strides of the innermost dimension.
llvm-svn: 209695
Support a 'keep-going' mode for the ScopDetection. In this mode, we just keep
on detecting, even if we encounter an error.
This is useful for diagnosing SCoP candidates. Sometimes you want all the
errors. Invalid SCoPs will still be refused in the end, we just refuse to
abort on the first error.
llvm-svn: 209574
This stores all RejectReasons created for one region
in a RejectLog inside the DetectionContext. For now
this only keeps track of the last error.
A separate patch will enable the tracking of all errors.
This patch itself does no harm (yet).
llvm-svn: 209572
definition below all of the header #include lines, Polly edition.
If you want to know more details about this, you can see the recent
commits to Debug.h in LLVM. This is just the Polly segment of a cleanup
I'm doing globally for this macro.
llvm-svn: 206852
The following example shows a non-parallel loop
void f(int a[]) {
int i;
for (i = 0; i < 10; ++i)
A[i] = A[i+5];
}
which, in case we import a schedule that limits the iteration domain
to 0 <= i < 5, becomes parallel. Previously we crashed in such cases, now we
just recognize it as parallel.
This fixes http://llvm.org/PR19435
Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
llvm-svn: 206318
We update to a newer version of isl, which includes changes to the compute
out facility that make it a lot more predicable. With our new value, we can
reliably bail out for all reported bugs, while still being able to compute
dependences for all but two test cases in the LLVM test suite. For the remaining
two test cases, the dependence problem we construct is unnecessarily complex,
so there is hope we can improve on this. However, to avoid any future issues,
having a reliable compute out facility in place is important.
llvm-svn: 206106
This replaces the ancient INVALID/INVALID_NOVERIFY macros with a real
function.
The new invalid(..) function uses small diagnostic objects that are
generated on demand. We can store arbitrary additional information per
error type and generate useful debug/error messages on the fly.
Use it as follows:
if (/* Some error condition (ReportFoo) */)
invalid<ReportFoo>(Context, /*Assert=*/true/false,
(/* List of helpful diagnostic objects */));
Where ReportFoo is a subclass of RejectReason that is able to take the
list of helpful diagnostic objects in its constructor.
The implementation of invalid will create the report and fire
an assertion, if necessary.
llvm-svn: 205414
For complex examples it may happen that we do not compute dependences. In this
case we do not want to crash, but just not detect parallel loops.
llvm-svn: 204470
llvm.org/PR19081 reports that the polly dependence analysis causes some h264
compilation to hang. We adjust the compute out, to ensure we do not block on
expensive dependence calculations.
llvm-svn: 204168
Value::user_iterator changes in LLVM r203364. Converts several of these
loops to nice range based loops in the process.
Built and tested cleanly for me, yay for being able to fully build and
test Polly changes!
llvm-svn: 203381
The module LLVMPolly.so links to that. There is really no reason to build a
large number of mini-libraries here, especially as we do have dependences
between the libraries that are not properly handled and that make linking fail
on darwin.
Submitted-by: David Fang <fang@csl.cornell.edu>
llvm-svn: 202743
We mostly iterate over read-only values. Following a suggestion by Duncan P.N
Exons Smith, we use the construct 'const auto &' for this.
llvm-svn: 202651
clang-format requires a space before the ":" in the foreach loop. Even though
this is surprising to me, we follow this style to make our formatting
consistent with clang-format. I found that this clang-format style is used in a
couple of C++11 examples, hence I believe the fact that clang-format adds a
colon is not a bug but just something I was not used to yet.
llvm-svn: 202648
In case we do not have valid dependences, we do not run dead code elimination or
the schedule optimizer. This fixes an infinite loop in the dead code
elimination (PR12110).
llvm-svn: 201982
In case the domain of a statement is empty, the schedule optimizer set by
accident the schedule to a NULL pointer. This is incorrect. Instead, we set
it to an empty isl_map with zero schedule dimensions. We already checked for
this in our test cases, but unfortunately the test cases did not fail as
expected. The assert we add in this commit now ensures that the test cases
fail properly in case we regress on this again.
llvm-svn: 201886
This pass eliminates loop iterations that compute results that are not used
later on. This can help e.g. in D, where the default zero-initialization is
often unnecessary if right after new values are assigned to an array.
Contributed-by: Peter Conn <conn.peter@gmail.com>
llvm-svn: 201817
We do not have a use for this information at the moment. If we need this at some
point, the "instruction -> access" mapping needs to be enhanced as a single
instruction could then possibly perform multiple accesses.
This patch allows us to build the polyhedral information for scops with scalar
dependences.
llvm-svn: 201815
In rare cases the modification of one scop can effect the validity of other
scops, as code generation of an earlier scop may make the scalar evolution
functions derived for later scops less precise. The example that triggered this
patch was a scop that contained an 'or' expression as follows:
%add13710 = or i32 %j.19, 1
--> {(1 + (4 * %l)),+,2}<nsw><%for.body81>
Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This
information was not available after the first scop was code generated (or
independent-blocks was run on it) and SCEV could not derive a precise SCEV
expression any more. This means we could not any more code generate this SCoP.
My current understanding is that there is always the risk that an earlier code
generation change invalidates later scops. As the example we have seen here is
difficult to avoid, we use this occasion to guard us against all such
invalidations.
This patch "solves" this issue by verifying right before we start working on
a detected scop, if this scop is in fact still valid. This adds a certain
overhead. However the verification we run is anyways very fast and secondly
it is only run on detected scops. So the overhead should not be very large. As
a later optimization we could detect scops only on demand, such that we need
to run scop-detections always only a single time.
This should fix the single last failure in the LLVM test-suite for the new
scev-based code generation.
llvm-svn: 201593
Tobias Grosser