|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
031bb165 |
| 28-Mar-2019 |
Michael Kruse <[email protected]> |
Apply include-what-you-use #include removal suggestions. NFC.
This removes unused includes (and forward declarations) as suggested by include-what-you-use. If a transitive include of a removed inclu
Apply include-what-you-use #include removal suggestions. NFC.
This removes unused includes (and forward declarations) as suggested by include-what-you-use. If a transitive include of a removed include is required to compile a file, I added the required header (or forward declaration if suggested by include-what-you-use).
This should reduce compilation time and reduce the number of iterative recompilations when a header was changed.
llvm-svn: 357209
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1 |
|
| #
03346c27 |
| 14-Jul-2017 |
Siddharth Bhat <[email protected]> |
[PPCGCodeGeneration] Fix runtime check adjustments since they make assumptions about BB layout.
- There is a conditional branch that is used to switch between the old and new versions of the code
[PPCGCodeGeneration] Fix runtime check adjustments since they make assumptions about BB layout.
- There is a conditional branch that is used to switch between the old and new versions of the code.
- If we detect that the build was unsuccessful, `PPCGCodeGeneration` will change the runtime check to be always set to false.
- To actually *reach* this runtime check instruction, `PPCGCodeGeneration` was using assumptions about the layout of the BBs.
- However, invariant load hoisting violates this assumption by inserting an extra basic block in the middle.
- Fix the assumption on the layout by having `createScopConditionally` return the conditional branch instruction.
- Use this reference to set to always-false.
llvm-svn: 308010
show more ...
|
| #
256070d8 |
| 26-Jun-2017 |
Andreas Simbuerger <[email protected]> |
[NFC] Return both polly.start and polly.exiting from executeScopConditionally.
This commit returns both the start and the exit block that are created by executeScopConditionally.
In a future commit
[NFC] Return both polly.start and polly.exiting from executeScopConditionally.
This commit returns both the start and the exit block that are created by executeScopConditionally.
In a future commit we will make use of the exit block. Before we would have to use the implicit property that there won't be any code generated between polly.start and polly.exiting at the time of use to find the correct block ('polly.exiting').
All usage location are semantically unchanged.
llvm-svn: 306283
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
| #
2d950f36 |
| 04-Apr-2017 |
Philip Pfaffe <[email protected]> |
[Polly][NewPM] Pull references to the legacy PM interface from utilities and helpers
Summary: A couple of the utilities used to analyze or build IR make explicit use of the legacy PM on their interf
[Polly][NewPM] Pull references to the legacy PM interface from utilities and helpers
Summary: A couple of the utilities used to analyze or build IR make explicit use of the legacy PM on their interface, to access analysis results. This patch removes the legacy PM from the interface, and just passes the required results directly.
This shouldn't introduce any function changes, although the API technically allowed to obtain two different analysis results before, one passed by reference and one through the PM. I don't believe that was ever intended, however.
Reviewers: grosser, Meinersbur
Reviewed By: grosser
Subscribers: nemanjai, pollydev, llvm-commits
Tags: #polly
Differential Revision: https://reviews.llvm.org/D31653
llvm-svn: 299423
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
acf80064 |
| 02-Nov-2016 |
Eli Friedman <[email protected]> |
[Polly CodeGen] Break critical edge from RTC to original loop.
This makes polly generate a CFG which is closer to what we want in LLVM IR, with a loop preheader for the original loop. This is just a
[Polly CodeGen] Break critical edge from RTC to original loop.
This makes polly generate a CFG which is closer to what we want in LLVM IR, with a loop preheader for the original loop. This is just a cleanup, but it exposes some fragile assumptions.
I'm not completely happy with the changes related to expandCodeFor; RTCBB->getTerminator() is basically a random insertion point which happens to work due to the way we generate runtime checks. I'm not sure what the right answer looks like, though.
Differential Revision: https://reviews.llvm.org/D26053
llvm-svn: 285864
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
ef74443c |
| 23-May-2016 |
Johannes Doerfert <[email protected]> |
Duplicate part of the Region interface in the Scop class [NFC]
This allows to use the SCoP directly for various queries, thus to hide the underlying region more often.
llvm-svn: 270426
|
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1 |
|
| #
2d3d4ec8 |
| 09-Dec-2015 |
Tobias Grosser <[email protected]> |
executeScopConditionally: Introduce special exiting block
When introducing separate control flow for the original and optimized code we introduce now a special 'ExitingBlock':
\ / Enter
executeScopConditionally: Introduce special exiting block
When introducing separate control flow for the original and optimized code we introduce now a special 'ExitingBlock':
\ / EnteringBB | SplitBlock---------\ _____|_____ | / EntryBB \ StartBlock | (region) | | \_ExitingBB_/ ExitingBlock | | MergeBlock---------/ | ExitBB / \
This 'ExitingBlock' contains code such as the final_reloads for scalars, which previously were just added to whichever statement/loop_exit/branch-merge block had been generated last. Having an explicit basic block makes it easier to find these constructs when looking at the CFG.
llvm-svn: 255107
show more ...
|
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3 |
|
| #
d2b03601 |
| 18-Aug-2015 |
Michael Kruse <[email protected]> |
Fix Codegen adding a second exit out of region
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 cr
Fix Codegen adding a second exit out of region
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
show more ...
|
| #
22370884 |
| 11-Aug-2015 |
Michael Kruse <[email protected]> |
Revise the simplification of regions
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
Revise the simplification of regions
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
show more ...
|
|
Revision tags: llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1 |
|
| #
7c3bad52 |
| 27-May-2015 |
Tobias Grosser <[email protected]> |
Use value semantics for list of ScopStmt(s) instead of std::owningptr
David Blaike suggested this as an alternative to the use of owningptr(s) for our memory management, as value semantics allow to
Use value semantics for list of ScopStmt(s) instead of std::owningptr
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
show more ...
|
| #
679dfafd |
| 23-May-2015 |
Tobias Grosser <[email protected]> |
Use unique_ptr to clarify ownership of ScopStmt
llvm-svn: 238090
|
|
Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
| #
ba0d0922 |
| 09-May-2015 |
Tobias Grosser <[email protected]> |
Sort include directives
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 in
Sort include directives
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
show more ...
|
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
| #
f32d651d |
| 01-Mar-2015 |
Johannes Doerfert <[email protected]> |
[Refactor] Include explicitly what is used
llvm-svn: 230901
|
|
Revision tags: llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2 |
|
| #
62975f55 |
| 19-Jan-2015 |
Chandler Carruth <[email protected]> |
[PM] Update Polly for LLVM r226459 which removed another pass argument from an API in the process of preparing for the new pass manager.
llvm-svn: 226460
|
| #
6adcf56b |
| 18-Jan-2015 |
Chandler Carruth <[email protected]> |
[PM] Update Polly for LLVM r226385 which made LoopInfo actually derive from LoopInfoBase<...>, removing the need for the awkward getBase() dance.
llvm-svn: 226387
|
| #
f557987b |
| 17-Jan-2015 |
Chandler Carruth <[email protected]> |
[PM] Update Polly following LLVM r226373 which refactors LoopInfo in preparation for the new pass manager.
llvm-svn: 226374
|
|
Revision tags: llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1 |
|
| #
38262244 |
| 10-Sep-2014 |
Johannes Doerfert <[email protected]> |
[Refactor] Cleanup isl code generation
Summary: + Refactor the runtime check (RTC) build function + Added helper function to create an PollyIRBuilder + Change the simplify region function to c
[Refactor] Cleanup isl code generation
Summary: + Refactor the runtime check (RTC) build function + Added helper function to create an PollyIRBuilder + Change the simplify region function to create not only unique entry and exit edges but also enfore that the entry edge is unconditional + Cleaned the IslCodeGeneration runOnScop function: - less post-creation changes of the created IR + Adjusted and added test cases
Reviewers: grosser, sebpop, simbuerg, dpeixott
Subscribers: llvm-commits, #polly
Differential Revision: http://reviews.llvm.org/D5076
llvm-svn: 217508
show more ...
|
|
Revision tags: llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3 |
|
| #
28735947 |
| 16-Aug-2014 |
Tobias Grosser <[email protected]> |
Revert "[Refactor] Cleanup runtime code generation"
This reverts commit 215466 (and 215528, a trivial formatting fix).
The intention of these commits is a good one, but unfortunately they broke our
Revert "[Refactor] Cleanup runtime code generation"
This reverts commit 215466 (and 215528, a trivial formatting fix).
The intention of these commits is a good one, but unfortunately they broke our LNT buildbot:
http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-codegen-isl
Several of the cleanup changes that have been combined in this 'fixup' are trivial and could probably be committed as obvious changes without risking to break the build. The remaining changes are little and it should be easy to figure out what went wrong.
llvm-svn: 215817
show more ...
|
| #
5b1a0442 |
| 13-Aug-2014 |
Tobias Grosser <[email protected]> |
Fix formatting
llvm-svn: 215528
|
| #
9744c4af |
| 12-Aug-2014 |
Johannes Doerfert <[email protected]> |
[Refactor] Cleanup runtime code generation
+ Use regexp in two test case. + Refactor the runtime condition build function
llvm-svn: 215466
|
|
Revision tags: llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
8ca36815 |
| 19-Jul-2014 |
Matt Arsenault <[email protected]> |
Update for RegionInfo changes.
Mostly related to missing includes and renaming of the pass to RegionInfoPass.
llvm-svn: 213457
|
| #
083d3d3c |
| 28-Jun-2014 |
Tobias Grosser <[email protected]> |
[C++11] Use more range based fors
llvm-svn: 211981
|
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
5103ba7c |
| 04-Mar-2014 |
Tobias Grosser <[email protected]> |
Introduce PollyIRBuilder
PollyIRBuilder is currently just a typedef to IRBuilder<>. Consequently, this change should not affect behavior. In subsequent patches we will extend its functionality to em
Introduce PollyIRBuilder
PollyIRBuilder is currently just a typedef to IRBuilder<>. Consequently, this change should not affect behavior. In subsequent patches we will extend its functionality to emit loop.parallel metadata.
llvm-svn: 202853
show more ...
|
| #
472d3b70 |
| 24-Feb-2014 |
Tobias Grosser <[email protected]> |
codegen: Update LoopInfo correctly
Add the 'polly.start' basic block to the loop that surrounds the scop we just codegenerate.
This fixes PR13441
llvm-svn: 202000
|