summaryrefslogtreecommitdiffstats
path: root/polly/test/Isl/CodeGen/MemAccess
Commit message (Collapse)AuthorAgeFilesLines
* [ScopBuilder] Make -polly-stmt-granularity=scalar-indep the default.Michael Kruse2018-02-033-5/+5
| | | | | | | | | | | | | | | | | | | | Splitting basic blocks into multiple statements if there are now additional scalar dependencies gives more freedom to the scheduler, but more statements also means higher compile-time complexity. Switch to finer statement granularity, the additional compile time should be limited by the number of operations quota. The regression tests are written for the -polly-stmt-granularity=bb setting, therefore we add that flag to those tests that break with the new default. Some of the tests only fail because the statements are named differently due to a basic block resulting in multiple statements, but which are removed during simplification of statements without side-effects. Previous commits tried to reduce this effect, but it is not completely avoidable. Differential Revision: https://reviews.llvm.org/D42151 llvm-svn: 324169
* [IRBuilder] Only emit alias scop metadata for arrays, but not scalarsTobias Grosser2017-08-221-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is no need to emit alias metadata for scalars, as basicaa will easily distinguish them from arrays. This reduces the size of the metadata we generate. This is especially useful after we moved to -polly-position=before-vectorizer, where a lot more scalar dependences are introduced, which increased the size of the alias analysis metadata and made us commonly reach the limits after which we do not emit alias metadata that have been introduced to prevent quadratic growth of this alias metadata. This improves 2mm performance from 1.5 seconds to 0.17 seconds. Reviewers: Meinersbur, bollu, singam-sanjay Reviewed By: Meinersbur Subscribers: pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D37028 llvm-svn: 311498
* [JSON] Make the failure to parse a jscop file a hard errorPhilip Pfaffe2017-08-101-1/+1
| | | | | | | | | | | | | | | | | | Summary: Before, if we fail to parse a jscop file, this will be reported as an error and importing is aborted. However, this isn't actually strong enough, since although the import is aborted, the scop has already been modified and is very likely broken. Instead, make this a hard failure and throw an LLVM error. This new behaviour requires small changes to the tests for the legacy pass, namely using `not` to verify the error. Further, fixed the jscop file for the base_pointer_load_is_inst_inside_invariant_1 testcase. Reviewed By: Meinersbur Split out of D36578. llvm-svn: 310599
* [ScopInfo] Simplify new access functions under domain contextTobias Grosser2017-07-171-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: We do not keep domain constraints on access functions when building the scop. Hence, for consistency reasons, it makes also sense to not include them when storing a new access function. This change results in simpler access functions that make output easier to read. This patch also helps to make DeLICMed memory accesses to be understood by our matrix multiplication pattern matching pass. Further changes to the matrix multiplication pattern matching are needed for this to work, so the corresponding test case will be added in a future commit. Reviewers: Meinersbur, bollu, gareevroman, efriedma, huihuiz, sebpop, simbuerg Subscribers: pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D35237 llvm-svn: 308215
* [tests] Set -polly-import-jscop-dir=%S alwaysTobias Grosser2017-07-1118-24/+24
| | | | | | This simplifies the test cases. llvm-svn: 307645
* Heap allocation for new arrays.Michael Kruse2017-06-283-0/+255
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch aims to implement the option of allocating new arrays created by polly on heap instead of stack. To enable this option, a key named 'allocation' must be written in the imported json file with the value 'heap'. We need such a feature because in a next iteration, we will implement a mechanism of maximal static expansion which will need a way to allocate arrays on heap. Indeed, the expansion is very costly in terms of memory and doing the allocation on stack is not worth considering. The malloc and the free are added respectively at polly.start and polly.exiting such that there is no use-after-free (for instance in case of Scop in a loop) and such that all memory cells allocated with a malloc are free'd when we don't need them anymore. We also add : - In the class ScopArrayInfo, we add a boolean as member called IsOnHeap which represents the fact that the array in allocated on heap or not. - A new branch in the method allocateNewArrays in the ISLNodeBuilder for the case of heap allocation. allocateNewArrays now takes a BBPair containing polly.start and polly.exiting. allocateNewArrays takes this two blocks and add the malloc and free calls respectively to polly.start and polly.exiting. - As IntPtrTy for the malloc call, we use the DataLayout one. To do that, we have modified : - createScopArrayInfo and getOrCreateScopArrayInfo such that it returns a non-const SAI, in order to be able to call setIsOnHeap in the JSONImporter. - executeScopConditionnaly such that it return both start block and end block of the scop, because we need this two blocs to be able to add the malloc and the free calls at the right position. Differential Revision: https://reviews.llvm.org/D33688 llvm-svn: 306540
* [CodeGen] Emit aliasing metadata for new arrays.Michael Kruse2017-06-191-0/+12
| | | | | | | | | | | | Ensure that all array base pointers are assigned before generating aliasing metadata by allocating new arrays beforehand. Before this patch, getBasePtr() returned nullptr for new arrays because the arrays were created at a later point. Nullptr did not match to any array after the created array base pointers have been assigned and when the loads/stores are generated. llvm-svn: 305675
* [Polly] Generate more 'canonical' induction variableHongbin Zheng2017-05-122-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Today Polly generates induction variable in this way: polly.indvar = phi 0, polly.indvar.next ... polly.indvar.next = polly.indvar + stide polly.loop_cond = predicate polly.indvar, (UB - stride) Instead of: polly.indvar = phi 0, polly.indvar.next ... polly.indvar.next = polly.indvar + stide polly.loop_cond = predicate polly.indvar.next, UB The way Polly generate induction variable cause some problem in the indvar simplify pass. This patch make polly generate the later form, by assuming the induction variable never overflow Differential Revision: https://reviews.llvm.org/D33089 llvm-svn: 302866
* Relax assert when setting access functions with invariant base pointersTobias Grosser2017-01-171-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of forbidding such access functions completely, we verify that their base pointer has been hoisted and only assert in case the base pointer was not hoisted. I was trying for a little while to get a test case that ensures the assert is correctly fired in case of invariant load hoisting being disabled, but I could not find a good way to do so, as llvm-lit immediately aborts if a command yields a non-zero return value. As we do not generally test our asserts, not having a test case here seems OK. This resolves http://llvm.org/PR31494 Suggested-by: Michael Kruse <llvm@meinersbur.de> Reviewers: efriedma, jdoerfert, Meinersbur, gareevroman, sebpop, zinob, huihuiz, pollydev Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D28798 llvm-svn: 292213
* test: harden test case to fail even in non-asserts buildTobias Grosser2017-01-171-0/+2
| | | | | | | The original test case was added in r292147. Suggested-by: Michael Kruse <llvm@meinersbur.de> llvm-svn: 292202
* Add test showing the update of access functions with in-scop defined base ptrsTobias Grosser2017-01-162-0/+95
| | | | | | | | | This feature is currently not supported and an explicit assert to prevent the introduction of such accesses has been added in r282893. This test case allows to reproduce the assert (and without the assert the miscompile) added in r282893. It will help when adding such support at some point. llvm-svn: 292147
* [CodeGen] Add flag to code-generate most memory access expressionsTobias Grosser2016-11-221-0/+58
| | | | | | | | | | | | | | Introduce the new flag -polly-codegen-generate-expressions which forces Polly to code generate AST expressions instead of using our SCEV based access expression generation even for cases where the original memory access relation was not changed and the SCEV based access expression could be code generated without any issue. This is an experimental option for better testing the isl ast expression generation. The default behavior of Polly remains unchanged. We also exclude a couple of cases for which the AST expression is not yet working. llvm-svn: 287694
* Store the size of the outermost dimension in case of newly created arrays ↵Roman Gareev2016-09-125-13/+14
| | | | | | | | | | | | | that require memory allocation. We do not need the size of the outermost dimension in most cases, but if we allocate memory for newly created arrays, that size is needed. Reviewed-by: Michael Kruse <llvm@meinersbur.de> Differential Revision: https://reviews.llvm.org/D23991 llvm-svn: 281234
* Allow mapping scalar MemoryAccesses to array elements.Michael Kruse2016-09-013-0/+315
| | | | | | | | | | | | | | | | | | | | | | Change the code around setNewAccessRelation to allow to use a an existing array element for memory instead of an ad-hoc alloca. This facility will be used for DeLICM/DeGVN to convert scalar dependencies into regular ones. The changes necessary include: - Make the code generator use the implicit locations instead of the alloca ones. - A test case - Make the JScop importer accept changes of scalar accesses for that test case. - Adapt the MemoryAccess interface to the fact that the MemoryKind can change. They are named (get|is)OriginalXXX() to get the status of the memory access before any change by setNewAccessRelation() (some properties such as getIncoming() do not change even if the kind is changed and are still required). To get the modified properties, there is (get|is)LatestXXX(). The old accessors without Original|Latest become synonyms of the (get|is)OriginalXXX() to not make functional changes in unrelated code. Differential Revision: https://reviews.llvm.org/D23962 llvm-svn: 280408
* Add space between access string and follow-up.Michael Kruse2016-08-263-5/+5
| | | | llvm-svn: 279826
* [FIX] Access dimensions should correspond to number of dimensions of the ↵Roman Gareev2016-08-262-4/+6
| | | | | | accesses array. llvm-svn: 279821
* Add a flag to dump SCoP optimized with the IslScheduleOptimizer passRoman Gareev2016-08-211-86/+0
| | | | | | | | | | | | | Dump polyhedral descriptions of Scops optimized with the isl scheduling optimizer and the set of post-scheduling transformations applied on the schedule tree to be able to check the work of the IslScheduleOptimizer pass at the polyhedral level. Reviewed-by: Tobias Grosser <tobias@grosser.es> Differential Revision: https://reviews.llvm.org/D23740 llvm-svn: 279395
* Perform replacement of access relations and creation of new arrays according ↵Roman Gareev2016-08-151-0/+86
| | | | | | | | | | | | | | | | | | | | to the packing transformation This is the third patch to apply the BLIS matmul optimization pattern on matmul kernels (http://www.cs.utexas.edu/users/flame/pubs/TOMS-BLIS-Analytical.pdf). BLIS implements gemm as three nested loops around a macro-kernel, plus two packing routines. The macro-kernel is implemented in terms of two additional loops around a micro-kernel. The micro-kernel is a loop around a rank-1 (i.e., outer product) update. In this change we perform replacement of the access relations and create empty arrays, which are steps to implement the packing transformation. In subsequent changes we will implement copying to created arrays. Reviewed-by: Tobias Grosser <tobias@grosser.es> Differential Revision: http://reviews.llvm.org/D22187 llvm-svn: 278666
* Add missing prefixes.Roman Gareev2016-07-301-7/+7
| | | | llvm-svn: 277264
* Extend the jscop interface to allow the user to declare new arrays and to ↵Roman Gareev2016-07-303-0/+165
| | | | | | | | | | | | | | | | reference these arrays from access expressions Extend the jscop interface to allow the user to export arrays. It is required that already existing arrays of the list of arrays correspond to arrays of the SCoP. Each array that is appended to the list will be newly created. Furthermore, we allow the user to modify access expressions to reference any array in case it has the same element type. Reviewed-by: Tobias Grosser <tobias@grosser.es> Differential Revision: https://reviews.llvm.org/D22828 llvm-svn: 277263
* tests: make test cases more robust using regexpTobias Grosser2016-07-211-3/+3
| | | | llvm-svn: 276262
* tests: fix order of memory accesses to ensure import succeedsTobias Grosser2016-07-213-20/+28
| | | | | | | | | | | It seems the order in which we generated memory accesses changed such that the import of these updated memory accesses failed for the 'loop3' statement in this test case. Unfortunately, the existing CHECK lines were not strict enough to catch this. Hence, besides fixing the order of the memory access lines we also ensure that the memory access changes are both clearly visibly and well checked. llvm-svn: 276247
* This reverts recent expression type changesTobias Grosser2016-06-117-67/+46
| | | | | | | | | | | | | | | | | | | | | The recent expression type changes still need more discussion, which will happen on phabricator or on the mailing list. The precise list of commits reverted are: - "Refactor division generation code" - "[NFC] Generate runtime checks after the SCoP" - "[FIX] Determine insertion point during SCEV expansion" - "Look through IntToPtr & PtrToInt instructions" - "Use minimal types for generated expressions" - "Temporarily promote values to i64 again" - "[NFC] Avoid unnecessary comparison for min/max expressions" - "[Polly] Fix -Wunused-variable warnings (NFC)" - "[NFC] Simplify min/max expression generation" - "Simplify the type adjustment in the IslExprBuilder" Some of them are just reverted as we would otherwise get conflicts. I will try to re-commit them if possible. llvm-svn: 272483
* [NFC] Generate runtime checks after the SCoPJohannes Doerfert2016-06-062-16/+16
| | | | | | | | | We now generate runtime checks __after__ the SCoP code generation and not before, though they are still inserted at the same position int the code. This allows to modify the runtime check during SCoP code generation. llvm-svn: 271894
* Use minimal types for generated expressionsJohannes Doerfert2016-06-067-41/+62
| | | | | | | | | | | | We now use the minimal necessary bit width for the generated code. If operations might overflow (add/sub/mul) we will try to adjust the types in order to ensure a non-wrapping computation. If the type adjustment is not possible, thus the necessary type is bigger than the type value of --polly-max-expr-bit-width, we will use assumptions to verify the computation will not wrap. However, for run-time checks we cannot build assumptions but instead utilize overflow tracking intrinsics. llvm-svn: 271878
* Allow pointer expressions in SCEVs again.Johannes Doerfert2016-04-102-12/+13
| | | | | | | | | In r247147 we disabled pointer expressions because the IslExprBuilder did not fully support them. This patch reintroduces them by simply treating them as integers. The only special handling for pointers that is left detects the comparison of two address_of operands and uses an unsigned compare. llvm-svn: 265894
* Make memory accesses with different element types optionalTobias Grosser2016-02-071-0/+1
| | | | | | | | We also disable this feature by default, as there are still some issues in combination with invariant load hoisting that slipped through my initial testing. llvm-svn: 260025
* Follow uses to create value MemoryAccessesMichael Kruse2016-02-061-2/+2
| | | | | | | | | | | | | | | | | | | | The previously implemented approach is to follow value definitions and create write accesses ("push defs") while searching for uses. This requires the same relatively validity- and requirement conditions to be replicated at multiple locations (PHI instructions, other instructions, uses by PHIs). We replace this by iterating over the uses in a SCoP ("pull in requirements"), and add writes only when at least one read has been added. It turns out to be simpler code because each use is only iterated over once and writes are added for the first access that reads it. We need another iteration to identify escaping values (uses not in the SCoP), which also makes the difference between such accesses more obvious. As a side-effect, the order of scalar MemoryAccess can change. Differential Revision: http://reviews.llvm.org/D15706 llvm-svn: 259987
* Support accesses with differently sized types to the same arrayTobias Grosser2016-02-042-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows code such as: void multiple_types(char *Short, char *Float, char *Double) { for (long i = 0; i < 100; i++) { Short[i] = *(short *)&Short[2 * i]; Float[i] = *(float *)&Float[4 * i]; Double[i] = *(double *)&Double[8 * i]; } } To model such code we use as canonical element type of the modeled array the smallest element type of all original array accesses, if type allocation sizes are multiples of each other. Otherwise, we use a newly created iN type, where N is the gcd of the allocation size of the types used in the accesses to this array. Accesses with types larger as the canonical element type are modeled as multiple accesses with the smaller type. For example the second load access is modeled as: { Stmt_bb2[i0] -> MemRef_Float[o0] : 4i0 <= o0 <= 3 + 4i0 } To support code-generating these memory accesses, we introduce a new method getAccessAddressFunction that assigns each statement instance a single memory location, the address we load from/store to. Currently we obtain this address by taking the lexmin of the access function. We may consider keeping track of the memory location more explicitly in the future. We currently do _not_ handle multi-dimensional arrays and also keep the restriction of not supporting accesses where the offset expression is not a multiple of the access element type size. This patch adds tests that ensure we correctly invalidate a scop in case these accesses are found. Both types of accesses can be handled using the very same model, but are left to be added in the future. We also move the initialization of the scop-context into the constructor to ensure it is already available when invalidating the scop. Finally, we add this as a new item to the 2.9 release notes Reviewers: jdoerfert, Meinersbur Differential Revision: http://reviews.llvm.org/D16878 llvm-svn: 259784
* Revert "Support loads with differently sized types from a single array"Tobias Grosser2016-02-032-107/+0
| | | | | | This reverts commit (@259587). It needs some further discussions. llvm-svn: 259629
* Support loads with differently sized types from a single arrayTobias Grosser2016-02-022-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We support now code such as: void multiple_types(char *Short, char *Float, char *Double) { for (long i = 0; i < 100; i++) { Short[i] = *(short *)&Short[2 * i]; Float[i] = *(float *)&Float[4 * i]; Double[i] = *(double *)&Double[8 * i]; } } To support such code we use as element type of the modeled array the smallest element type of all original array accesses. Accesses with larger types are modeled as multiple accesses with the smaller type. For example the second load access is modeled as: { Stmt_bb2[i0] -> MemRef_Float[o0] : 4i0 <= o0 <= 3 + 4i0 } To support jscop-rewritable memory accesses we need each statement instance to only be assigned a single memory location, which will be the address at which we load the value. Currently we obtain this address by taking the lexmin of the access function. We may consider keeping track of the memory location more explicitly in the future. llvm-svn: 259587
* ScopInfo: Look up first (and only) array accessTobias Grosser2015-12-153-0/+140
| | | | | | | | | | When rewriting the access functions of load/store statements, we are only interested in the actual array memory location. The current code just took the very first memory access, which could be a scalar or an array access. As a result, we failed to update access functions even though this was requested via .jscop. llvm-svn: 255713
* tests: Drop -polly-detect-unprofitable and -polly-no-early-exitTobias Grosser2015-10-0612-16/+16
| | | | | | | | These flags are now always passed to all tests and need to be disabled if not needed. Disabling these flags, rather than passing them to almost all tests, significantly simplfies our RUN: lines. llvm-svn: 249422
* Reapply "BlockGenerator: Generate synthesisable instructions only on-demand"Tobias Grosser2015-09-301-4/+4
| | | | | | | | | | | | | | | Instructions which we can synthesis from a SCEV expression are not generated directly, but only when they are used as an operand of another instruction. This avoids generating unnecessary instructions and works more reliably than first inserting them and then deleting them later on. This commit was reverted in r248860 due to a remaining miscompile, where we forgot to synthesis the operand values that were referenced from scalar writes. test/Isl/CodeGen/scalar-store-from-same-bb.ll tests that we do this now correctly. llvm-svn: 248900
* Revert "BlockGenerator: Generate synthesisable instructions only on-demand"Johannes Doerfert2015-09-291-4/+4
| | | | | | | | | | | | This reverts commit 07830c18d789ee72812d5b5b9b4f8ce72ebd4207. The commit broke at least one test in lnt, MultiSource/Benchmarks/Ptrdist/bc/number.c was miss compiled and the test produced a wrong result. One Polly test case that was added later was adjusted too. llvm-svn: 248860
* Codegen: Support memory accesses with different typesTobias Grosser2015-09-292-0/+99
| | | | | | | | | | | | | | | | | | | | | | Every once in a while we see code that accesses memory with different types, e.g. to perform operations on a piece of memory using type 'float', but to copy data to this memory using type 'int'. Modeled in C, such codes look like: void foo(float A[], float B[]) { for (long i = 0; i < 100; i++) *(int *)(&A[i]) = *(int *)(&B[i]); for (long i = 0; i < 100; i++) A[i] += 10; } We already used the correct types during normal operations, but fall back to our detected type as soon as we import changed memory access functions. For these memory accesses we may generate invalid IR due to a mismatch between the element type of the array we detect and the actual type used in the memory access. To address this issue, we always cast the newly created address of a memory access back to the type of the memory access where the address will be used. llvm-svn: 248781
* BlockGenerator: Be less agressive with deleting dead instructionsTobias Grosser2015-09-271-1/+2
| | | | | | | | | | | | | | We now only delete trivially dead instructions in the BB we copy (copyBB), but not in any other BB. Only for copyBB we know that there will _never_ be any future uses of instructions that have no use after copyBB has been generated. Other instructions in the AST that have been generated by IslNodeBuilder may look dead at the moment, but may possibly still be referenced by GlobalMaps. If we delete them now, later uses would break surprisingly. We do not have a test case that breaks due to us deleting too many instructions. This issue was found by inspection. llvm-svn: 248688
* BlockGenerator: Simplify code generated for scop statementsTobias Grosser2015-09-271-2/+1
| | | | | | | | | | | After having generated a new user statement a couple of inefficient or trivially dead instructions may remain. This commit runs instruction simplification over the newly generated blocks to ensure unneeded instructions are removed right away. This commit does not yet add simplification for non-affine subregions. llvm-svn: 248681
* Clean-up unit testsMichael Kruse2015-09-102-4/+0
| | | | | | Remove redundant flags and duplicate invocations of the same test. llvm-svn: 247285
* Use base-pointer address space when creating new access functionsTobias Grosser2015-05-201-0/+44
| | | | llvm-svn: 237785
* Rename IslCodeGeneration to CodeGenerationTobias Grosser2015-05-127-13/+13
| | | | | | | | | 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
* Remove target triples from test casesTobias Grosser2015-04-214-4/+0
| | | | | | | | I just learned that target triples prevent test cases to be run on other architectures. Polly test cases are until now sufficiently target independent to not require any target triples. Hence, we drop them. llvm-svn: 235384
* Test case updates for explicit type parameter to the gep operatorDavid Blaikie2015-03-136-34/+34
| | | | llvm-svn: 232186
* Update Polly tests to handle explicitly typed load changes in LLVM.David Blaikie2015-02-275-12/+12
| | | | llvm-svn: 230796
* Update Polly tests to handle explicitly typed gep changes in LLVMDavid Blaikie2015-02-2710-23/+23
| | | | llvm-svn: 230784
* ScopDetection: Only detect scops that have at least one read and one writeTobias Grosser2015-02-1910-17/+17
| | | | | | | | | | Scops that only read seem generally uninteresting and scops that only write are most likely initializations where there is also little to optimize. To not waste compile time we bail early. Differential Revision: http://reviews.llvm.org/D7735 llvm-svn: 229820
* Add early exits for SCoPs we did not optimizeJohannes Doerfert2015-02-115-11/+11
| | | | | | | | | | | | | This allows us to skip ast and code generation if we did not optimize a SCoP and will not generate parallel or alias annotations. The initial heuristic to exit is simple but allows improvements later on. All failing test cases have been modified to disable early exit, thus to keep their coverage. Differential Revision: http://reviews.llvm.org/D7254 llvm-svn: 228851
* [NFC] Drop the "scattering" tuple nameJohannes Doerfert2015-02-0215-17/+17
| | | | llvm-svn: 227801
* Remove -polly-codegen-scev option and related codeTobias Grosser2014-11-303-5/+5
| | | | | | | | 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
* Switch default code generation backend to islTobias Grosser2014-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The isl based backend has been tested since a long time and with the recently commited OpenMP support the last missing piece of functionality was ported from the CLooG backend. The isl based backend gives us interesting new functionality: - Run-time alias checks (enabled by default) Optimize scops that contain possibly aliasing pointers. This feature has largely increased the number of loop nests we consider for optimization. Thanks Johannes! - Delinearization (not yet enabled by default) Model accesses to multi-dimensional arrays precisely. This will allow us to understand kernels with multi-dimensional VLAs written in Julia, boost::ublas, coremark or C99. Thanks Sebastian! - Generation of higher quality code Sven and me spent a long time to optimize the quality of the generated code. A major focus were expressions as they result from modulos/divisions or piecewise affine expressions (a ? b : c). - Full/Partial tile separation, polyhedral unrolling The isl code generation provides functionality to generate specialized code for core and cleanup loops and to specialize code using polyhedral context information while unrolling statements. (not yet exploited in Polly) - Modifieable access functions We can now use standard isl functionality to remap memory accesses to new data locations. A standard use case is the use of shared memory, where accesses to a larger region in global memory need to be mapped to a smaller shared memory region using a modulo mapping. (not yet exploited in Polly) The cloog based code generation is still available for comparision, but is scheduled for removal. llvm-svn: 222101
OpenPOWER on IntegriCloud