summaryrefslogtreecommitdiffstats
path: root/polly/test/Isl/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [Fortran Support] Materialize outermost dimension for Fortran array.Siddharth Bhat2017-05-191-0/+82
| | | | | | | | | | | | | | | | | | | - We use the outermost dimension of arrays since we need this information to generate GPU transfers. - In general, if we do not know the outermost dimension of the array (because the indexing expression is non-affine, for example) then we simply cannot generate transfer code. - However, for Fortran arrays, we can use the Fortran array representation which stores the dimensions of all arrays. - This patch uses the Fortran array representation to generate code that computes the outermost dimension size. Differential Revision: https://reviews.llvm.org/D32967 llvm-svn: 303429
* [Polly] Generate more 'canonical' induction variableHongbin Zheng2017-05-126-14/+13
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Polly] Canonicalize arrays according to base-ptr equivalence classTobias Grosser2017-05-101-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In case two arrays share base pointers in the same invariant load equivalence class, we canonicalize all memory accesses to the first of these arrays (according to their order in the equivalence class). This enables us to optimize kernels such as boost::ublas by ensuring that different references to the C array are interpreted as accesses to the same array. Before this change the runtime alias check for ublas would fail, as it would assume models of the C array with differing (but identically valued) base pointers would reference distinct regions of memory whereas the referenced memory regions were indeed identical. As part of this change we remove most of the MemoryAccess::get*BaseAddr interface. We removed already all references to get*BaseAddr in previous commits to ensure that no code relies on matching base pointers between memory accesses and scop arrays -- except for three remaining uses where we need the original base pointer. We document for these situations that MemoryAccess::getOriginalBaseAddr may return a base pointer that is distinct to the base pointer of the scop array referenced by this memory access. Reviewers: sebpop, Meinersbur, zinob, gareevroman, pollydev, huihuiz, efriedma, jdoerfert Reviewed By: Meinersbur Subscribers: etherzhhb Tags: #polly Differential Revision: https://reviews.llvm.org/D28518 llvm-svn: 302636
* Adjust test case to not trigger the SCEV optimization committed in r302096Tobias Grosser2017-05-041-1/+1
| | | | | | | | | This makes sure we still test the case that a PHI-NODE cannot be analyzed by scalar evolution and consequently must be code generated explicitly. As Michael's optimization triggers only on a very specific "add %iv, %step" pattern, just changing 'add' to 'mul' adds back test coverage. llvm-svn: 302132
* [tests] Ensure all test cases use named variablesTobias Grosser2017-04-284-71/+70
| | | | | | | | | | | | | | | This makes it easier to read and possibly even modify the test cases, as there is no need to keep the variable increment in steps of one. More importantly, by using explicit variable names we do not need to rely on the implicit numbering of statements when dumping the scop information. This makes it easier to read and possibly even modify the test cases. Furthermore, by using explicit variables we do not need to rely on the implicit numbering of statements when dumping the scop information. In a future commit, this implicit numbering will likely not be used any more to refer to LLVM-IR values as it is very expensive to construct. llvm-svn: 301689
* [ScopInfo] Consider only write-free dereferencable loads as invariantTobias Grosser2017-04-271-9/+6
| | | | | | | | | | | | | When we introduced in r297375 support for hoisting loads that are known to be dereferencable without any conditional guard, we forgot to keep the check to verify that no other write into the very same location exists. This change ensures now that dereferencable loads are allowed to access everything, but can only be hoisted in case no conflicting write exists. This resolves llvm.org/PR32778 Reported-by: Huihui Zhang <huihuiz@codeaurora.org> llvm-svn: 301582
* [Polly] Do not introduce address space castHongbin Zheng2017-04-271-0/+40
| | | | | | | | Do not introduce address space cast in IslNodeBuilder::preloadUnconditionally. Differential Revision: https://reviews.llvm.org/D32581 llvm-svn: 301519
* Remove llvm.lifetime.start/end in original region.Michael Kruse2017-04-051-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The current StackColoring algorithm does not correctly handle the situation when some, but not all paths from a BB to the entry node cross a llvm.lifetime.start. According to an interpretation of the language reference at http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic this might be correct, but it would cost too much effort to handle in StackColoring. To be on the safe side, remove all lifetime markers even in the original code version (they have never been copied to the optimized version) to ensure that no path to the entry block will cross a llvm.lifetime.start. The same principle applies to paths the a function return and the llvm.lifetime.end marker, so we remove them as well. This fixes llvm.org/PR32251. Also see the discussion at http://lists.llvm.org/pipermail/llvm-dev/2017-March/111551.html llvm-svn: 299585
* [CodeGen] Add Performance MonitorTobias Grosser2017-04-031-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for -polly-codegen-perf-monitoring. When performance monitoring is enabled, we emit performance monitoring code during code generation that prints after program exit statistics about the total number of cycles executed as well as the number of cycles spent in scops. This gives an estimate on how useful polyhedral optimizations might be for a given program. Example output: Polly runtime information ------------------------- Total: 783110081637 Scops: 663718949365 In the future, we might also add functionality to measure how much time is spent in optimized scops and how many cycles are spent in the fallback code. Reviewers: bollu,sebpop Tags: #polly Differential Revision: https://reviews.llvm.org/D31599 llvm-svn: 299359
* [test] Fix two testcases. NFC.Michael Kruse2017-04-031-2/+2
| | | | | | | | | | | | Trivial fix for two testcases. When Polly isn't linked into opt, independent of whether it's built in-tree or not, these testcases forget to load the appropriate library. Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com> Differential Revision: https://reviews.llvm.org/D31596 llvm-svn: 299357
* Add test case for r299352.Tobias Grosser2017-04-031-0/+200
| | | | llvm-svn: 299353
* Map the new load to the base pointer of the invariant load hoisted loadRoman Gareev2017-03-221-0/+32
| | | | | | | | | | | Map the new load to the base pointer of the invariant load hoisted load to be able to find the alias information for it. Reviewed-by: Tobias Grosser <tobias@grosser.es> Differential Revision: https://reviews.llvm.org/D30605 llvm-svn: 298507
* [CodeGen] Remove need for all parameters to be in scop context for load ↵Tobias Grosser2017-03-181-0/+36
| | | | | | | | | | | hoisting. When not adding constraints on parameters using -polly-ignore-parameter-bounds, the context may not necessarily list all parameter dimensions. To support code generation in this situation, we now always iterate over the actual parameter list, rather than relying on the context to list all parameter dimensions. llvm-svn: 298197
* [OpenMP] Do not emit lifetime markers for contextTobias Grosser2017-03-183-11/+3
| | | | | | | | | | | | | | | | | | In commit r219005 lifetime markers have been introduced to mark the lifetime of the OpenMP context data structure. However, their use seems incorrect and recently caused a miscompile in ASC_Sequoia/CrystalMk after r298053 which was not at all related to r298053. r298053 only caused a change in the loop order, as this change resulted in a different isl internal representation which caused the scheduler to derive a different schedule. This change then caused the IR to change, which apparently created a pattern in which LLVM exploites the lifetime markers. It seems we are using the OpenMP context outside of the lifetime markers. Even though CrystalMk could probably be fixed by expanding the scope of the lifetime markers, it is not clear what happens in case the OpenMP function call is in a loop which will cause a sequence of starting and ending lifetimes. As it is unlikely that the lifetime markers give any performance benefit, we just drop them to remove complexity. llvm-svn: 298192
* [ScopDetect/Info] Allow unconditional hoisting of loads from dereferenceable ↵Tobias Grosser2017-03-091-10/+8
| | | | | | | | | | | | ptrs In case LLVM pointers are annotated with !dereferencable attributes/metadata or LLVM can look at the allocation from which a pointer is derived, we can know that dereferencing pointers is safe and can be done unconditionally. We use this information to proof certain pointers as save to hoist and then hoist them unconditionally. llvm-svn: 297375
* [ScopDetection] Only allow SCoP-wide available base pointers.Michael Kruse2017-03-081-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify ScopDetection::isInvariant(). Essentially deny everything that is defined within the SCoP and is not load-hoisted. The previous understanding of "invariant" has a few holes: - Expressions without side-effects with only invariant arguments, but are defined withing the SCoP's region with the exception of selects and PHIs. These should be part of the index expression derived by ScalarEvolution and not of the base pointer. - Function calls with that are !mayHaveSideEffects() (typically functions with "readnone nounwind" attributes). An example is given below. @C = external global i32 declare float* @getNextBasePtr(float*) readnone nounwind ... %ptr = call float* @getNextBasePtr(float* %A, float %B) The call might return: * %A, so %ptr aliases with it in the SCoP * %B, so %ptr aliases with it in the SCoP * @C, so %ptr aliases with it in the SCoP * a new pointer everytime it is called, such as malloc() * a pointer into the allocated block of one of the aforementioned * any of the above, at random at each call Hence and contrast to a comment in the base_pointer.ll regression test, %ptr is not necessarily the same all the time. It might also alias with anything and no AliasAnalysis can tell otherwise if the definition is external. It is hence not suitable in the role of a base pointer. The practical problem with base pointers defined in SCoP statements is that it is not available globally in the SCoP. The statement instance must be executed first before the base pointer can be used. This is no problem if the base pointer is transferred as a scalar value between statements. Uses of MemoryAccess::setNewAccessRelation may add a use of the base pointer anywhere in the array. setNewAccessRelation is used by JSONImporter, DeLICM and D28518. Indeed, BlockGenerator currently assumes that base pointers are available globally and generates invalid code for new access relation (referring to the base pointer of the original code) if not, even if the base pointer would be available in the statement. This could be fixed with some added complexity and restrictions. The ExprBuilder must lookup the local BBMap and code that call setNewAccessRelation must check whether the base pointer is available first. The code would still be incorrect in the presence of aliasing. There is the switch -polly-ignore-aliasing to explicitly allow this, but it is hardly a justification for the additional complexity. It would still be mostly useless because in most cases either getNextBasePtr() has external linkage in which case the readnone nounwind attributes cannot be derived in the translation unit itself, or is defined in the same translation unit and gets inlined. Reviewed By: grosser Differential Revision: https://reviews.llvm.org/D30695 llvm-svn: 297281
* [ScopDetection] Require LoadInst base pointers to be hoisted.Michael Kruse2017-03-072-4/+4
| | | | | | | | | | | | | | | | | | Only when load-hoisted we can be sure the base pointer is invariant during the SCoP's execution. Most of the time it would be added to the required hoists for the alias checks anyway, except with -polly-ignore-aliasing, -polly-use-runtime-alias-checks=0 or if AliasAnalysis is already sure it doesn't alias with anything (for instance if there is no other pointer to alias with). Two more parts in Polly assume that this load-hoisting took place: - setNewAccessRelation() which contains an assert which tests this. - BlockGenerator which would use to the base ptr from the original code if not load-hoisted (if the access expression is regenerated) Differential Revision: https://reviews.llvm.org/D30694 llvm-svn: 297195
* [tests] Make sure tests do not end in 'unreachable' - Part IIITobias Grosser2017-03-073-5/+5
| | | | | | | | | | There is no point in optimizing unreachable code, hence our test cases should always return. This commit is part of a series that makes Polly more robust on the presence of unreachables. llvm-svn: 297158
* [tests] Make sure tests do not end in 'unreachable' - Part IITobias Grosser2017-03-075-8/+8
| | | | | | | | | | There is no point in optimizing unreachable code, hence our test cases should always return. This commit is part of a series that makes Polly more robust on the presence of unreachables. llvm-svn: 297150
* [tests] Make sure tests do not end in 'unreachable'Tobias Grosser2017-03-072-2/+2
| | | | | | | | | | There is no point in optimizing unreachable code, hence our test cases should always return. This commit is part of a series that makes Polly more robust on the presence of unreachables. llvm-svn: 297147
* Updated isl to isl-0.18-254-g6bc184dTobias Grosser2017-02-171-1/+1
| | | | | | | This update includes a couple more coalescing changes as well as a large number of isl-internal code cleanups (dead assigments, ...). llvm-svn: 295419
* [IRBuilder] Extract base pointers directly from ScopArrayTobias Grosser2017-02-091-3/+3
| | | | | | | | | | | | | Instead of iterating over statements and their memory accesses to extract the set of available base pointers, just directly iterate over all ScopArray objects. This reflects more the actual intend of the code: collect all arrays (and their base pointers) to emit alias information that specifies that accesses to different arrays cannot alias. This change removes unnecessary uses of MemoryAddress::getBaseAddr() in preparation for https://reviews.llvm.org/D28518. llvm-svn: 294574
* BlockGenerator: Do not redundantly reload from PHI-allocas in non-affine stmtsTobias Grosser2017-01-191-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change we created an additional reload in the copy of the incoming block of a PHI node to reload the incoming value, even though the necessary value has already been made available by the normally generated scalar loads. In this change, we drop the code that generates this redundant reload and instead just reuse the scalar value already available. Besides making the generated code slightly cleaner, this change also makes sure that scalar loads go through the normal logic, which means they can be remapped (e.g. to array slots) and corresponding code is generated to load from the remapped location. Without this change, the original scalar load at the beginning of the non-affine region would have been remapped, but the redundant scalar load would continue to load from the old PHI slot location. It might be possible to further simplify the code in addOperandToPHI, but this would not only mean to pull out getNewValue, but to also change the insertion point update logic. As this did not work when trying it the first time, this change is likely not trivial. To not introduce bugs last minute, we postpone further simplications to a subsequent commit. We also document the current behavior a little bit better. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D28892 llvm-svn: 292486
* Improve test coverage in test/Isl/CodeGen/loop_partially_in_scop.ll [NFC]Tobias Grosser2017-01-191-20/+37
| | | | | | | | | | | | | | We rename the test case with -metarenamer to make the variable names easier to read and add additional check lines that verify the code we currently generate for PHI nodes. This code is interesting as it contains a PHI node in a non-affine sub-region, where some incoming blocks are within the non-affine sub-region and others are outside of the non-affine subregion. As can be seen in the check lines we currently load the PHI-node value twice. This commit documents this behavior. In a subsequent patch we will try to improve this. llvm-svn: 292470
* 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
* Fix debug info metadata for upstream change in LLVM.Adrian Prantl2016-12-201-1/+1
| | | | llvm-svn: 290154
* Revert "Fix debug info metadata for upstream change in LLVM."Adrian Prantl2016-12-161-1/+1
| | | | llvm-svn: 289983
* Fix debug info metadata for upstream change in LLVM.Adrian Prantl2016-12-161-1/+1
| | | | llvm-svn: 289953
* [ScopInfo] Fold constant coefficients in array dimensions to the rightTobias Grosser2016-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This allows us to delinearize code such as the one below, where the array sizes are A[][2 * n] as there are n times two elements in the innermost dimension. Alternatively, we could try to generate another dimension for the struct in the innermost dimension, but as the struct has constant size, recovering this dimension is easy. struct com { double Real; double Img; }; void foo(long n, struct com A[][n]) { for (long i = 0; i < 100; i++) for (long j = 0; j < 1000; j++) A[i][j].Real += A[i][j].Img; } int main() { struct com A[100][1000]; foo(1000, A); llvm-svn: 288489
* [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
* [test] Simplify test case by removing unreferenced instructions [NFC]Tobias Grosser2016-11-221-4/+0
| | | | | | | | | Drop instructions that do not influence the memory impact of a basic block. They are not needed to reproduce the original bug (verified) and will cause random test noise if we would decide to only model the instructions that have visible side-effects. llvm-svn: 287626
* [test] Ensure important basic blocks in test case have side effectsTobias Grosser2016-11-221-4/+36
| | | | | | | | | | Add two store instructions at the end of basic blocks that are required to reproduce the original bug to ensure we always process and model these basic blocks. This makes this test case stable even in case we would decide to bail out early of basic blocks which do not modify the global state. Also add additional check lines to verify how we model the basic block. llvm-svn: 287625
* IslAst: always use the context during ast generationTobias Grosser2016-11-101-16/+4
| | | | | | | | | | | | | | | | | | | Providing the context to the ast generator allows for additional simplifcations and -- more importantly -- allows to generate loops with only partially bounded domains, assuming the domains are bounded for all parameter configurations that are valid as defined by the context. This change fixes the crash reported in http://llvm.org/PR30956 The original reason why we did not include the context when generating an AST was that CLooG and later isl used to sometimes transfer some of the constraints that bound the size of parameters from the context into the generated AST. This resulted in operations with very large constants, which sometimes introduced problematic integer overflows. The latest versions of the isl AST generator are careful to not introduce such constants. Reported-by: Eli Friedman <efriedma@codeaurora.org> llvm-svn: 286442
* Handle multi-dimensional invariant load.Eli Friedman2016-10-171-0/+54
| | | | | | | If the address of a load depends on another load, make sure to emit the loads in the right order. llvm-svn: 284426
* Adapt test case to recent change in Global Variable DefinitionTobias Grosser2016-09-131-1/+1
| | | | llvm-svn: 281295
* 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
* [BlockGenerator] Invalidate SCEV values for instructions in scopTobias Grosser2016-08-181-1/+3
| | | | | | | | | | | | | | | We already invalidated a couple of critical values earlier on, but we now invalidate all instructions contained in a scop after the scop has been code generated. This is necessary as later scops may otherwise obtain SCEV expressions that reference values in the earlier scop that before dominated the later scop, but which had been moved into the conditional branch and consequently do not dominate the later scop any more. If these very values are then used during code generation of the later scop, we generate used that are dominated by the values they use. This fixes: http://llvm.org/PR28984 llvm-svn: 279047
* [test] Force invariant load hoisting one last timeTobias Grosser2016-08-151-1/+2
| | | | | | | Without invariant load hoisting an (unrelated) bug is exposed in this test case: http://llvm.org/PR28984 llvm-svn: 278680
* [tests] Force invariant load hoisting for test cases that need it -- IIITobias Grosser2016-08-156-6/+12
| | | | llvm-svn: 278673
* [tests] Force invariant load hoisting for test cases that need it IITobias Grosser2016-08-1510-12/+24
| | | | llvm-svn: 278669
* [tests] Force invariant load hoisting for test cases that need itTobias Grosser2016-08-1527-31/+31
| | | | | | | | This will make it easier to switch the default of Polly's invariant load hoisting strategy and also makes it very clear that these test cases indeed require invariant code hoisting to work. llvm-svn: 278667
* 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
* [BlockGenerator] Insert initializations at beginning of start blockTobias Grosser2016-08-093-3/+3
| | | | | | | | | | | | | | In case some code -- not guarded by control flow -- would be emitted directly in the start block, it may happen that this code would use uninitalized scalar values if the scalar initialization is only emitted at the end of the start block. This is not a problem today in normal Polly, as all statements are emitted in their own basic blocks, but Polly-ACC emits host-to-device copy statements into the start block. Additional Polly-ACC test coverage will be added in subsequent changes that improve the handling of PHI nodes in Polly-ACC. llvm-svn: 278124
* Add missing prefixes.Roman Gareev2016-07-301-7/+7
| | | | llvm-svn: 277264
OpenPOWER on IntegriCloud