| Age | Commit message (Collapse) | Author |
|---|
|
llvm-svn: 239008
|
|
llvm-svn: 238929
|
|
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
|
|
Power-of-two floor divisions can be translated into an arithmetic shift
operation. This allows us to replace a complex lowering that requires division
operations:
%pexp.fdiv_q.0 = sub i64 %21, 128
%pexp.fdiv_q.1 = add i64 %pexp.fdiv_q.0, 1
%pexp.fdiv_q.2 = icmp slt i64 %21, 0
%pexp.fdiv_q.3 = select i1 %pexp.fdiv_q.2, i64 %pexp.fdiv_q.1, i64 %21
%pexp.fdiv_q.4 = sdiv i64 %pexp.fdiv_q.3, 128
with a simple ashr:
%polly.fdiv_q.shr = ashr i64 %21, 7
llvm-svn: 238905
|
|
llvm-svn: 238645
|
|
llvm-svn: 238644
|
|
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
|
|
This update brings mostly interface cleanups, but also fixes two bugs in
imath (a memory leak, some undefined behavior).
llvm-svn: 238422
|
|
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
|
|
llvm-svn: 238257
|
|
llvm-svn: 238092
|
|
llvm-svn: 238091
|
|
llvm-svn: 238090
|
|
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
|
|
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
|
|
llvm-svn: 237800
|
|
This condition was accidentally introduced in r211875.
llvm-svn: 237796
|
|
llvm-svn: 237785
|
|
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
|
|
The IRBuilder::CreateCall interface was changed in r237624 and now requires an
initializer list.
llvm-svn: 237666
|
|
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
|
|
Suggested-by: Johannes Doerfert
llvm-svn: 237441
|
|
Suggested-by: Johannes Doerfert
llvm-svn: 237440
|
|
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
|
|
This fixes a bug in the isl scheduler (http://llvm.org/PR21934)
Otherwise mostly minor changes.
llvm-svn: 237250
|
|
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
|
|
This reverts commit 236875. Daniel fixed the clang-format bug that introduced
the changed formatting.
llvm-svn: 236994
|
|
Various smaller improvements and bugfixes.
llvm-svn: 236932
|
|
llvm-svn: 236931
|
|
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
|
|
llvm-svn: 236875
|
|
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
|
|
Ran the same rename-md-di-prefix.sh script attached to PR23080 as in
LLVM r236120 and CFE r236121.
llvm-svn: 236127
|
|
The IslNodeBuilder is a generic class that may be useful in other contexts
as well. Hence, we extract it into its own .h/.cpp file.
llvm-svn: 235873
|
|
llvm-svn: 235871
|
|
Without this patch Polly with GPGPU support enabled did not compile any more.
llvm-svn: 235868
|
|
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
|
|
In the following even full-range information will help to avoid
runtime checks for wrapping integers, hence we enable it now.
llvm-svn: 235823
|
|
llvm-svn: 235822
|
|
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
|
|
llvm-svn: 235381
|
|
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
|
