summaryrefslogtreecommitdiffstats
path: root/polly/lib/CodeGen/BlockGenerators.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [PM] Update Polly for LLVM r226394 and r226396 which changed some of theChandler Carruth2015-01-181-2/+12
| | | | | | | block splitting interfaces to accept specific analyses rather than a pass. llvm-svn: 226398
* [PM] Update Polly following LLVM r226373 which refactors LoopInfo inChandler Carruth2015-01-171-4/+4
| | | | | | preparation for the new pass manager. llvm-svn: 226374
* Remove -polly-codegen-scev option and related codeTobias Grosser2014-11-301-21/+8
| | | | | | | | SCEV based code generation has been the default for two weeks after having been tested for a long time. We now drop the support the non-scev-based code generation. llvm-svn: 222978
* Enable SCEV based code generation by defaultTobias Grosser2014-11-161-1/+1
| | | | | | | | | | | | | | | | | | | SCEV based code generation allows Polly to detect and generate code for loops that do not have an explicit induction variable, but only virtual induction variables given by SCEV. Being able to do so has two main benefits: - We can detect more scops by default - We require less canonicalization before Polly, which means we get closer to our goal of not touching the IR before analyzing its properties. Specifically, we do not need to run -polly-indvars to introduce explicit canonical induction variables. This switch became possible as both the isl code generation and -polly-parallel are LNT error free with SCEV based code generation and the isl ast generator. llvm-svn: 222113
* BlockGenerator: Recompute values from SCEV before handing back the original ↵Tobias Grosser2014-11-051-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | values This patch moves the SCEV based (re)generation of values before the checking for scop-constant terms. It enables us to provide SCEV based replacements, which are necessary to correctly generate OpenMP subfunctions when using the SCEV based code generation. When recomputing a new value for a value used in the code of the original scop, we previously directly returned the same original value for all scop-constant expressions without even trying to regenerate these values using our SCEV expression. This is correct when the newly generated code remains fully in the same function, however in case we want to outline parts of the newly generated scop into subfunctions, this approach means we do not have any opportunity to update these values in the SCEV based code generation. (In the non-SCEV based code generation, we can provide such updates through the GlobalMap). To ensure we have this opportunity, we first try to regenerate scalar terms with our SCEV builder and will only return scop-constant expressions if SCEV based code generation was not possible. This change should not affect the results of the existing code generation passes. It only impacts the upcoming OpenMP based code generation. This commit also adds a test case. This test case passes before and after this commit. It was added to ensure test coverage for the changed code. llvm-svn: 221393
* BlockGenerator: inline lookupAvailableValue into getValue [NFC]Tobias Grosser2014-11-051-11/+3
| | | | | | | | | | | There was no good reason why this code was split accross two functions. In subsequent changes we will change the order in which values are looked up. Doing so would make the split into two functions even more arbitrary. We also slightly improve the documentation. llvm-svn: 221388
* Remove incorrect value description for -enable-polly-alignedTobias Grosser2014-10-221-5/+4
| | | | | | | | | The description of the parameter value passed to -enable-polly-aligned did not make any sense at all, but was just a leftover coming from when this option was copied form -enable-polly-openmp. We just drop it as the option description gives sufficient information already. llvm-svn: 220445
* [Refactor][NfC] Simplify and clean the handling of (new) access relationsJohannes Doerfert2014-10-131-17/+5
| | | | | | | | | | | | | | | This patch does not change the semantic on it's own. However, the dependence analysis as well as dce will now use the newest available access relation for each memory access, thus if at some point the json importer or any other pass will run before those two and set a new access relation the behaviour will be different. In general it is unclear if the dependence analysis and dce should be run on the old or new access functions anyway. If we need to access the original access function from the outside later, we can expose the getter again. Differential Revision: http://reviews.llvm.org/D5707 llvm-svn: 219612
* [Refactor][NFC] Simplify (Vector)BlockGeneratorJohannes Doerfert2014-10-081-5/+2
| | | | | | | | This removes an unnecessary cast and a unnecessary local variable. Differential Revision: http://reviews.llvm.org/D5662 llvm-svn: 219338
* Allow the VectorBlockGenerator to use the IslExprBuilder.Johannes Doerfert2014-10-081-13/+14
| | | | | | | This also enables the VectorBlockGenerator to build load store accesses according to the newAccessRelation of a MemoryAccess. llvm-svn: 219321
* Align copied load/store instructions as the original.Johannes Doerfert2014-10-021-3/+5
| | | | | | | | | | This also forbids the json importer to access other memory locations than the original instruction as we to reuse the alignment of the original load/store. Differential Revision: http://reviews.llvm.org/D5560 llvm-svn: 218883
* Allow the IslExprBuilder to build address of expressionsJohannes Doerfert2014-09-181-0/+1
| | | | llvm-svn: 218045
* Make used analysis passes explicitJohannes Doerfert2014-08-071-11/+10
| | | | | | | | Use the explicit analysis if possible, only for splitBlock we will continue to use the Pass * argument. This change allows us to remove the getAnalysis calls from the code generation. llvm-svn: 215121
* Fix the modifiable access creationJohannes Doerfert2014-08-031-145/+36
| | | | | | | | | | | | + Remove the class IslGenerator which duplicates the functionality of IslExprBuilder. + Use the IslExprBuilder to create code for memory access relations. + Also handle array types during access creation. + Enable scev codegen for one of the transformed memory access tests, thus access creation without canonical induction variables available. + Update one test case to the new output. llvm-svn: 214659
* [Refactor] Use non-const MemoryAccess base addressesJohannes Doerfert2014-07-291-1/+1
| | | | llvm-svn: 214168
* clang-format polly to avoid buildbot noiseTobias Grosser2014-07-091-6/+8
| | | | llvm-svn: 212609
* Use range-based for loopsTobias Grosser2014-06-041-20/+12
| | | | llvm-svn: 210170
* Really fix the load case.Tobias Grosser2014-04-181-0/+4
| | | | | | | | Commit r206510 falsely advertised to fix the load cases, even though it only fixed the store case. This commit adds the same fix for the load case including the missing test coverage. llvm-svn: 206577
* Ensure a scalar pointer when issuing a vector loadTobias Grosser2014-04-171-0/+4
| | | | | | | | | | | Even tough we may want to generate a vector load, the address from which to load still is a scalar. Make sure even if previous address computations may have been vectorized, that the addresses are also available as scalars. This fixes http://llvm.org/PR19469 Reported-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> llvm-svn: 206510
* [C++11] Use nullptrTobias Grosser2014-04-161-5/+5
| | | | llvm-svn: 206361
* clang-format: Remove empty linesTobias Grosser2014-03-211-2/+0
| | | | llvm-svn: 204468
* Support for generating vectors for loads with -1 strideTobias Grosser2014-03-191-6/+24
| | | | | | | | This patch enables vectorization of loops containing backward array traversal (array stride is -1). Contributed-by: Chris Jenneisch <chrisj@codeaurora.org> llvm-svn: 204257
* Introduce PollyIRBuilderTobias Grosser2014-03-041-4/+4
| | | | | | | | 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
* Codegen: Do not crash when seeing debug intrinsicsTobias Grosser2014-02-211-0/+8
| | | | | | | | | | We now skip the debug intrinsics which is a lot better than crashing due to uncopied metadata references. We should step by step investigate which debug intrinsics we can copy without trouble. We still keep the debug location metadata. llvm-svn: 201860
* BlockGenerator: Split getNewValue.Hongbin Zheng2013-07-251-12/+24
| | | | | | | | | | | | Split the old getNewValue into two parts: 1. The function "lookupAvailableValue" that return the new version of the instruction which is already available. 2. The function calls "lookupAvailableValue", and tries to generate the new version if it is not available yet. llvm-svn: 187114
* BlockGenerator: Simplify the old value searching code.Hongbin Zheng2013-06-291-9/+5
| | | | | | | | | | | Orignally, we first test if a ValueMap contains a Value, and than use the index operator to get the corresponding new value. This requires the ValueMap to lookup the key (i.e. the old value) twice. Now, we directly use the "lookup" function provided by DenseMap to implement the same functionality. llvm-svn: 185260
* Refactor memory access getting code in ScopStmt.Hongbin Zheng2013-06-291-3/+3
| | | | | | | | | 1. Do not allow creating new memory access record in the InstructionToAccess map on the fly in function getAccessFor. 2. Do not allow user to modify the memory accesses returned by getAccessFor during the code generation process. llvm-svn: 185253
* Integrate latest clang-format changesTobias Grosser2013-06-231-1/+1
| | | | llvm-svn: 184655
* Use isl_val instead of isl_int in the core of PollyTobias Grosser2013-06-211-19/+11
| | | | | | | | | | | isl recently introduced isl_val as an abstract interface to represent arbitrary precision numbers. This interface superseeds the old isl_int interface. In contrast to the old interface which implemented arbitrary precision arithmetic using macros that forward to the gmp library, the new library hides the math library implementation in isl. This allows us to switch the math library used by isl without affecting users such as Polly. llvm-svn: 184529
* add comments to clarify the use of a temporary variable in the map insertionSebastian Pop2013-05-241-0/+4
| | | | llvm-svn: 182662
* fix insertion of values in BBMapSebastian Pop2013-05-241-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In GDB when "step" through generateScalarLoad and "finish" the call, the returned value is non NULL, however when printing the value contained in BBMap[Load] after this stmt: BBMap[Load] = generateScalarLoad(...); the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1. The only intuitive idea that I have to explain this behavior is that we are playing with the undefined behavior of eval order of the params for the function standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be executed before generateScalarLoad is called. Here are some other possible explanations from Will Dietz <w@wdtz.org>: The error is likely due to BBMap[Load] being evaluated first (creating a {Load -> uninitialized } entry in the DenseMap), then generateScalarLoad eventually accesses the same element and finds it to be NULL (DenseMap[Old]).. Offhand I'm not sure if this is guaranteed to be NULL or if it's uninitialized and happens to be NULL. The same issue can also go wrong in an even worse way: the second DenseMap access can trigger a rehash and *invalidate* the an earlier evaluated expression (for example LHS of the assignment), leading to a crash when performing the assignment store. llvm-svn: 182655
* Sort includesTobias Grosser2013-05-071-5/+3
| | | | llvm-svn: 181297
* Move polly options into separate option categoryTobias Grosser2013-05-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Use the new cl::OptionCategory support to move the Polly options into a separate option category. The aim is to hide most options and show by default only the options a user needs to influence '-O3 -polly'. The available options probably need some care, but here is the current status: Polly Options: Configure the polly loop optimizer -enable-polly-openmp - Generate OpenMP parallel code -polly - Enable the polly optimizer (only at -O3) -polly-no-tiling - Disable tiling in the scheduler -polly-only-func=<function-name> - Only run on a single function -polly-report - Print information about the activities of Polly -polly-vectorizer - Select the vectorization strategy =none - No Vectorization =polly - Polly internal vectorizer =unroll-only - Only grouped unroll the vectorize candidate loops =bb - The Basic Block vectorizer driven by Polly llvm-svn: 181295
* Reformat with clang-formatTobias Grosser2013-05-071-28/+39
| | | | | | | clang-format become way more stable. This time we mainly reformat function signatures. llvm-svn: 181294
* IndependentBlocks: We can only reconstruct PHI nodes that are within the ScoPTobias Grosser2013-04-171-1/+1
| | | | | | | | | | In the classical (non -polly-codegen-scev) mode, we assume that we can always recreate PHI nodes during code generation. This is not true. We can only reconstruct them from the polyhedral information, in case the entire loop of the PHI node is part of the SCoP and consequently the PHI node was translated in the polyhedral description. llvm-svn: 179674
* Update formatting to latest version of clang-formatTobias Grosser2013-04-101-4/+4
| | | | llvm-svn: 179160
* clang-format: Many more filesTobias Grosser2013-03-231-11/+8
| | | | | | | | | | | | | After this commit, polly is clang-format clean. This can be tested with 'ninja polly-check-format'. Updates to clang-format may change this, but the differences will hopefully be both small and general improvements to the formatting. We currently have some not very nice formatting for a couple of items, DEBUG() stmts for example. I believe the benefit of being clang-format clean outweights the not perfect layout of this code. llvm-svn: 177796
* codegen: properly instantiate SCEVs to the place where they are usedTobias Grosser2013-03-221-27/+40
| | | | | | | | | | | | | | | | | | | | Given the following code for (i = 0; i < 10; i++) { ; } S: A[i] = 0 When code generating S using scev based code generation, we need to retrieve the scev of 'i' at the location of 'S'. If we do not do this the scev that we obtain will be expressed as {0,+,1}_for and will reference loop iterators that do not surround 'S' and that we consequently do not know how to code generate. What we really want is the scev to be instantiated to the value of 'i' after the loop. This value is {10} and it can be code generated without troubles. llvm-svn: 177777
* Remove dependence on canonical induction variableTobias Grosser2013-03-201-23/+35
| | | | | | | | When using the scev based code generation, we now do not rely on the presence of a canonical induction variable any more. This commit prepares the path to (conditionally) disable the induction variable canonicalization pass. llvm-svn: 177548
* Correct function to decide if a SCEV can be ignoredSebastian Pop2013-03-181-9/+5
| | | | | | | | | | | When doing SCEV based code generation, we ignore instructions calculating values that are fully defined by a SCEV expression. The values that are calculated by this instructions are recalculated on demand. This commit improves the check to verify if certain instructions can be ignored and recalculated on demand. llvm-svn: 177313
* CodeGen: clang-formatTobias Grosser2013-02-221-37/+38
| | | | llvm-svn: 175872
* capitalize SCEV to match the current naming conventionSebastian Pop2013-02-151-1/+1
| | | | llvm-svn: 175306
* use apply and ScevParameterRewriter::rewrite instead of SCEVRewriterSebastian Pop2013-02-151-197/+5
| | | | llvm-svn: 175296
* add LoopToScev mapsSebastian Pop2013-02-151-33/+45
| | | | llvm-svn: 175295
* CodeGen: clang-format goodnessTobias Grosser2013-02-051-114/+94
| | | | | | The changed files are not yet clang-format clean, but we are getting close. llvm-svn: 174403
* Formatting: Break lines after binary operators such as '&&'Tobias Grosser2012-12-291-6/+6
| | | | | | | | | | | | | | assert(Condition && "Text"); -> assert(Condition && "Text); This aligns Polly with the style used in LLVM. llvm-svn: 171242
* Fix obvious formatting problems.Tobias Grosser2012-12-291-11/+7
| | | | | | | | | | | | | | | | | | | | | | We fix the following formatting problems found by clang-format: - 80 cols violations - Obvious problems with missing or too many spaces - multiple new lines in a row clang-format suggests many more changes, most of them falling in the following two categories: 1) clang-format does not at all format a piece of code nicely 2) The style that clang-format suggests does not match the style used in Polly/LLVM I consider differences caused by reason 1) bugs, which should be fixed by improving clang-format. Differences due to 2) need to be investigated closer to understand the cause of the difference and the solution that should be taken. llvm-svn: 171241
* change interface for isStrideSebastian Pop2012-12-181-9/+11
| | | | | | | | isStride now takes a partial schedule as input. Patch from Tobias Grosser <tobias@grosser.es>. llvm-svn: 170419
* Allow polly ask bb-vectorizer to vectorize the loop body.Hongbin Zheng2012-05-061-8/+3
| | | | llvm-svn: 156254
* SCEV based code generationTobias Grosser2012-04-271-1/+244
| | | | | | | | | | This is an incomplete implementation of the SCEV based code generation. When finished it will remove the need for -indvars -enable-iv-rewrite. For the moment it is still disabled. Even though it passes 'make polly-test', there are still loose ends especially in respect of OpenMP code generation. llvm-svn: 155717
OpenPOWER on IntegriCloud