summaryrefslogtreecommitdiffstats
path: root/polly/lib/CodeGen/BlockGenerators.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Refactor: Move the code generation related header files to ↵Hongbin Zheng2012-04-251-2/+1
| | | | | | include/polly/CodeGen. llvm-svn: 155547
* Refactor: Move the declaration of the BlockGenerator/VectorBlockGeneratorHongbin Zheng2012-04-251-0/+648
to standalone header and source files. llvm-svn: 155546
OpenPOWER on IntegriCloud