| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 309671
|
|
|
|
| |
llvm-svn: 309669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows -polly-optree to move instructions that depend on
synthesizable values.
The difficulty for synthesizable values is that their value depends on
the location. When it is moved over a loop header, and the SCEV
expression depends on the loop induction variable (SCEVAddRecExpr), it
would use the current induction variable instead of the last one.
At the moment we cannot forward PHI nodes such that crossing the header
of loops referenced by SCEVAddRecExpr is not possible (assuming the loop
header has at least two incoming blocks: for entering the loop and the
backedge, such any instruction to be forwarded must have a phi between
use and definition).
A remaining issue is when the forwarded value is used after the loop,
but is only synthesizable inside the loop. This happens e.g. if
ScalarEvolution is unable to determine the number of loop iterations or
the initial loop value. We do not forward in this situation.
Differential Revision: https://reviews.llvm.org/D36102
llvm-svn: 309609
|
|
|
|
|
|
|
|
| |
In addition to array and PHI writes, also allow scalar value writes.
The only kind of write not allowed are writes by functions
(including memcpy/memmove/memset).
llvm-svn: 309582
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows us to map functions such as exp, expf, expl, for which no
LLVM intrinsics exist. Instead, we link to NVIDIA's libdevice which provides
high-performance implementations of a wide range of (math) functions. We
currently link only a small subset, the exp, cos and copysign functions. Other
functions will be enabled as needed.
Reviewers: bollu, singam-sanjay
Reviewed By: bollu
Subscribers: tstellar, tra, nemanjai, pollydev, mgorny, llvm-commits, kbarton
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35703
llvm-svn: 309560
|
|
|
|
|
|
|
|
|
|
|
| |
verification failure"
This reverts commit r309490 as it triggers on our AOSP buildbut error messages
of the form:
inlinable function call in a function with debug info must have a !dbg location
llvm-svn: 309556
|
|
|
|
|
| |
Suggested-by: Maximilian Falkenstein <falkensm@student.ethz.ch>
llvm-svn: 309533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
failure
Summary:
**Remove debug metadata from instruction to be copied to prevent the source file's debug metadata being copied into GPUModule and eventually failing Module verification and ASM string codegeneration.**
When copying the instruction onto the Module meant for the GPU, debug metadata attached to an instruction causes all related metadata to be pulled into the Module, including the DICompileUnit, which is not listed in llvm.dbg.cu of the Module. This fails the verification of the Module and generation of the ASM string.
The only debug metadata of the instruction, the DebugLoc, is unset by this patch.
Reviewers: grosser, bollu, Meinersbur
Reviewed By: grosser, bollu
Subscribers: pollydev
Tags: #polly
Differential Revision: https://reviews.llvm.org/D35630
llvm-svn: 309490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Write coalescing combines write accesses that
- Write the same llvm::Value.
- Write to the same array.
- Unless they do not write anything in a statement instance (partial
writes), write to the same element.
- There is no other access between them that accesses the same element.
This is particularly useful after DeLICM, which leaves partial writes to
disjoint domains.
Differential Revision: https://reviews.llvm.org/D36010
llvm-svn: 309489
|
|
|
|
|
|
|
| |
These were wrongly assumed to be phi nodes that require
MemoryKind::PHI accesses.
llvm-svn: 309454
|
|
|
|
|
|
|
|
|
| |
list. NFC.
It should be empty anyways. In this case it would even be redundant
because we just all all instructions in region statements.
llvm-svn: 309453
|
|
|
|
| |
llvm-svn: 309402
|
|
|
|
|
|
| |
So follow-up cleanup do not need special handling for such accesses.
llvm-svn: 309401
|
|
|
|
|
|
| |
If we fail, throw an error for now. We can gracefully handle this later.
llvm-svn: 309387
|
|
|
|
|
|
|
|
|
|
| |
Ignore all functions whose name match a regex. Useful because creating a
regex that does *not* match a string is somewhat hard.
Example:
https://stackoverflow.com/questions/1240275/how-to-negate-specific-word-in-regex
llvm-svn: 309377
|
|
|
|
|
|
| |
parameters
llvm-svn: 309368
|
|
|
|
| |
llvm-svn: 309366
|
|
|
|
|
|
|
|
|
| |
This fixes a bug in isl_flow where triggering the compute out could result in
undefined or unexpected behavior. This fixes some recent regressions we saw
in the android buildbots. Thanks Eli Friedman for reducing the corresponding
test cases.
llvm-svn: 309274
|
|
|
|
|
|
|
|
|
|
|
|
| |
ScopBuilder and Simplify (through VirtualInstruction.cpp) previously
used this functionality in their own implementation. Refactor them
both into a common one into the Scop class.
BlockGenerator also makes use of a similiar functionality, but also
records outside users and takes place after region simplification.
Merging it as well would be more complicated.
llvm-svn: 309273
|
|
|
|
|
|
|
|
|
| |
After region exit simplification, the incoming block of a phi node in
the SCoP region's exit block lands outside of the region. Since we
treat SCoPs as if this already happened, we need to account for that
when looking for outside uses of scalars (i.e. escaping scalars).
llvm-svn: 309271
|
|
|
|
|
|
|
| |
A region statement's instruction list is always empty and ignored by the code
generator. Don't give the impression that it means anything.
llvm-svn: 309197
|
|
|
|
|
|
|
| |
The instruction list is ignored for region statements, there
is no reason to set it.
llvm-svn: 309196
|
|
|
|
|
|
|
|
|
| |
A PHI node's incoming block is the user of its operand, not the PHI's parent.
Assuming the PHINode's parent being the user lead to the removal of a
MemoryAccesses because its use was assumed to be inside of the SCoP.
llvm-svn: 309164
|
|
|
|
|
|
|
|
|
|
| |
Translate the ScheduleOptimizer to use the new isl C++ bindings.
Reviewed-by: Michael Kruse <llvm@meinersbur.de>
Differential Revision: https://reviews.llvm.org/D35845
llvm-svn: 309119
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since there will be no more a 1:1 correspondence between statements and
basic blocks, we would like to get rid of the method getStmtFor(BB)
and its uses. Here we remove one of its uses in ScopInfo by fetching
the statement in which the call instruction lies.
Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in>
Differential Revision: https://reviews.llvm.org/D35691
llvm-svn: 309110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the following loop:
int i;
for (i = 0; i < func(); i+=1)
;
SCoP:
for (int j = 0; j<n; j+=1)
S(i, j)
The value i is synthesizable in the SCoP that includes only the j-loop.
This is because i is fixed within the SCoP, it is irrelevant whether
it originates from another loop.
This fixes a strange case where a PHI was synthesiable in a SCoP,
but not its incoming value, triggering an assertion.
This should fix MultiSource/Applications/sgefa/sgefa of the
perf-x86_64-penryn-O3-polly-before-vectorizer-unprofitable buildbot.
llvm-svn: 309109
|
|
|
|
|
|
|
|
|
|
|
| |
It seems I still had some incomplete changes in the tree when committing.
In general, we only import changes from isl upstream. In this case, the
changes were especially unfortunate, as they broke the error management
in isl_flow.c and consequently caused regressions.
Thanks to Michael Kruse for spotting this mistake.
llvm-svn: 309039
|
|
|
|
|
|
|
|
|
|
|
| |
In future, there will be no more a 1:1 correspondence between statements
and basic blocks, the name `contains` does not correctly capture their
relationship. A BB may infact comprise of multiple statements; hence we
describe a statement 'representing' a basic block.
Differential Revision: https://reviews.llvm.org/D35838
llvm-svn: 308982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Invariant load hoisted scalars, and arrays whose size we can statically compute
to be 0 do not need to be allocated as arrays.
Invariant load hoisted scalars are sent to the kernel directly as parameters.
Earlier, we used to allocate `0` bytes of memory for these because our
computation of size from `PPCGCodeGeneration::getArraySize` would result in `0`.
Now, since we don't invariant loads as arrays in PPCGCodeGeneration, this
problem does not occur anymore.
Differential Revision: https://reviews.llvm.org/D35795
llvm-svn: 308971
|
|
|
|
| |
llvm-svn: 308927
|
|
|
|
| |
llvm-svn: 308923
|
|
|
|
| |
llvm-svn: 308895
|
|
|
|
| |
llvm-svn: 308893
|
|
|
|
| |
llvm-svn: 308892
|
|
|
|
| |
llvm-svn: 308887
|
|
|
|
|
|
| |
To make the meaning and distinction to FD_CanForwardTree clearer.
llvm-svn: 308886
|
|
|
|
|
|
|
| |
In particular, explain the difference between FD_CanForward
and FD_CanForwardTree.
llvm-svn: 308885
|
|
|
|
|
|
|
|
|
|
|
|
| |
Read-only values (values defined before the SCoP) require special
handing with -polly-analyze-read-only-scalars=true (which is the
default). If active, each use of a value requires a read access.
When a copied value uses a read-only value, we must also ensure that
such a MemoryAccess is available or is created.
Differential Revision: https://reviews.llvm.org/D35764
llvm-svn: 308876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
match.
Summary:
- We were using `.count` in `StringRef`, which matches substrings.
- We may want to use this for equality as well.
- Generalise this, so allow regexes as a parameter to `polly-only-func`.
Differential Revision: https://reviews.llvm.org/D35728
llvm-svn: 308875
|
|
|
|
|
|
|
|
| |
The cases DoIt==false and DoIt==true were mixed up.
Thanks to Siddharth for noticing.
llvm-svn: 308874
|
|
|
|
|
|
|
|
| |
prependInstrunction -> prependInstruction
Thanks Nandini for noticing.
llvm-svn: 308873
|
|
|
|
|
|
|
|
|
| |
Note: PPCGCodeGeneration::pollyBuildAstExprForStmt is at
https://reviews.llvm.org/D35770
Differential Revision: https://reviews.llvm.org/D35771
llvm-svn: 308870
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D35771
llvm-svn: 308869
|
|
|
|
|
|
| |
For some reason this one was missed earlier.
llvm-svn: 308845
|
|
|
|
| |
llvm-svn: 308843
|
|
|
|
| |
llvm-svn: 308842
|
|
|
|
| |
llvm-svn: 308841
|
|
|
|
|
|
| |
We also move related accessor functions
llvm-svn: 308840
|
|
|
|
| |
llvm-svn: 308839
|
|
|
|
| |
llvm-svn: 308838
|