summaryrefslogtreecommitdiffstats
path: root/polly/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [GPGPU] Fix compilation issue with latest CUDA upgrade to i128Tobias Grosser2017-07-281-4/+4
| | | | llvm-svn: 309366
* [ScopInfo] Rename ScopStmt::contains(BB) to represents(BB). NFC.Michael Kruse2017-07-251-2/+2
| | | | | | | | | | | In future, there will be no more a 1:1 correspondence between statements and basic blocks, the name `contains` does not correctly capture their relationship. A BB may infact comprise of multiple statements; hence we describe a statement 'representing' a basic block. Differential Revision: https://reviews.llvm.org/D35838 llvm-svn: 308982
* [PPCGCodeGeneration] Skip arrays with empty extent.Siddharth Bhat2017-07-251-4/+19
| | | | | | | | | | | | | | | | | Invariant load hoisted scalars, and arrays whose size we can statically compute to be 0 do not need to be allocated as arrays. Invariant load hoisted scalars are sent to the kernel directly as parameters. Earlier, we used to allocate `0` bytes of memory for these because our computation of size from `PPCGCodeGeneration::getArraySize` would result in `0`. Now, since we don't invariant loads as arrays in PPCGCodeGeneration, this problem does not occur anymore. Differential Revision: https://reviews.llvm.org/D35795 llvm-svn: 308971
* Move MemoryAccess::isStride* to isl++Tobias Grosser2017-07-241-4/+4
| | | | llvm-svn: 308927
* Move ScopArrayInfo::getFromAccessFunction and getFromId to isl++Tobias Grosser2017-07-242-7/+10
| | | | llvm-svn: 308892
* Convert GPUNodeBuilder::getArraySize to islcpp.Siddharth Bhat2017-07-241-8/+11
| | | | | | | | | Note: PPCGCodeGeneration::pollyBuildAstExprForStmt is at https://reviews.llvm.org/D35770 Differential Revision: https://reviews.llvm.org/D35771 llvm-svn: 308870
* [NFC] Move PPCGCodeGeneration::pollyBuildAstExprForStmt to isl++.Siddharth Bhat2017-07-241-19/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D35771 llvm-svn: 308869
* Move applyScheduleToAccessRelation to isl++Tobias Grosser2017-07-232-2/+3
| | | | llvm-svn: 308842
* Move MemoryAccess::getAddressFunction to isl++Tobias Grosser2017-07-232-2/+2
| | | | llvm-svn: 308841
* Move MemoryAccess::NewAccessRelation to isl++Tobias Grosser2017-07-233-8/+8
| | | | | | We also move related accessor functions llvm-svn: 308840
* Move MemoryAccess::id to isl++Tobias Grosser2017-07-233-58/+64
| | | | llvm-svn: 308836
* Move ScopArrayInfo to isl++Tobias Grosser2017-07-212-17/+19
| | | | | | This moves the full ScopArrayInfo class to isl++ llvm-svn: 308801
* [Polly][GPGPU] Added SPIR Code Generation and Corresponding Runtime Support ↵Philipp Schaad2017-07-211-11/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | for Intel Summary: Added SPIR Code Generation to the PPCG Code Generator. This can be invoked using the polly-gpu-arch flag value 'spir32' or 'spir64' for 32 and 64 bit code respectively. In addition to that, runtime support has been added to execute said SPIR code on Intel GPU's, where the system is equipped with Intel's open source driver Beignet (development version). This requires the cmake flag 'USE_INTEL_OCL' to be turned on, and the polly-gpu-runtime flag value to be 'libopencl'. The transformation of LLVM IR to SPIR is currently quite a hack, consisting in part of regex string transformations. Has been tested (working) with Polybench 3.2 on an Intel i7-5500U (integrated graphics chip). Reviewers: bollu, grosser, Meinersbur, singam-sanjay Reviewed By: grosser, singam-sanjay Subscribers: pollydev, nemanjai, mgorny, Anastasia, kbarton Tags: #polly Differential Revision: https://reviews.llvm.org/D35185 llvm-svn: 308751
* [ScopInfo] Print instructions in dump().Michael Kruse2017-07-211-1/+1
| | | | | | | | | | | | | | | | | | | Print a statement's instruction on dump() regardless of -polly-print-instructions. dump() is supposed to be used in the debugger only and never in regression tests. While debugging, get all the information we have and we are not bound to break anything. For non-dump purposes of print, forward the setting of -polly-print-instructions as parameters. Some calls to print() had to be changed because the PollyPrintInstructions setting is only available in ScopInfo.cpp. In ScheduleOptimizer.cpp, dump() was used in regression tests. That's not what dump() is for. The print parameter "PrintInstructions" will also be useful for an explicit print SCoP pass in a future patch. llvm-svn: 308746
* [NFC] [PPCGCodeGeneration] Print `verifyModule` failure to debug stream.Siddharth Bhat2017-07-211-0/+2
| | | | | | | If verifyModule fails, it is helpful to know why it failed. Add a log to the debug stream that prints the failure. llvm-svn: 308727
* Fix typo in function name Bllock -> BlockTobias Grosser2017-07-211-3/+3
| | | | llvm-svn: 308715
* [IslNodeBuilder] Relax complexity check in invariant loads and run it earlyTobias Grosser2017-07-201-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | When performing invariant load hoisting we check that invariant load expressions are not too complex. Up to this commit, we performed this check by counting the sum of dimensions in the access range as a very simple heuristic. This heuristic is a little too conservative, as it prevents hoisting for any scops with a very large number of parameters. Hence, we update the heuristic to only count existentially quantified dimensions and set dimensions. We expect this to still detect the problematic expressions in h264 because of which this check was originally introduced. For some unknown reason, this complexity check was originally committed in IslNodeBuilder. It really belongs in ScopInfo, as there is no point in optimizing a program which we could have known earlier cannot be code generated. The benefit of running the check early is that we can avoid to even hoist checks that are expensive to code generate as invariant loads. This can be seen in the changed tests, where we now indeed detect the scop, but just not invariant load hoist the complicated access. We also improve the formatting of the code, document it, and use isl++ to simplify expressions. llvm-svn: 308659
* Support fabs and copysign in Polly-ACCTobias Grosser2017-07-201-2/+6
| | | | llvm-svn: 308649
* [PPCGCodeGen] [3/3] Update PPCGCodeGen + tests to latest ppcg.Siddharth Bhat2017-07-201-20/+77
| | | | | | | | | | | | | | | | | | | | | This commit *WILL COMPILE*. 1. `PPCG` now uses `isl_multi_pw_aff` instead of an array of `pw_aff`. This needs us to adjust how we index array bounds and how we construct array bounds. 2. `PPCG` introduces two new kinds of nodes: `init_device` and `clear_device`. We should investigate what the correct way to handle these are. 3. `PPCG` has gotten smarter with its use of live range reordering, so some of the tests have a qualitative improvement. 4. `PPCG` changed its output style, so many test cases need to be updated to fit the new style for `polly-acc-dump-code` checks. Differential Revision: https://reviews.llvm.org/D35677 llvm-svn: 308625
* [NFC] [PPCGCodeGeneration] cleanup kills related code.Siddharth Bhat2017-07-181-24/+29
| | | | | | | | We extended kills in Polly to handle both `phi` nodes and scalars that are not used within the Scop. Update the comments and choice of variable names to reflect this. llvm-svn: 308279
* [PPCGCodeGeneration] Generate invariant loads before trying to generate IR.Siddharth Bhat2017-07-171-0/+1
| | | | | | | | | - We should call `preloadInvariantLoads` to make sure that code is generated for invariant loads in the kernel. Differential Revision: https://reviews.llvm.org/D35410 llvm-svn: 308187
* [PPCGCodeGeneration] Fix runtime check adjustments since they make ↵Siddharth Bhat2017-07-143-9/+14
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Invariant Loads] Do not consider invariant loads to have dependences.Siddharth Bhat2017-07-132-1/+28
| | | | | | | | | | | | | | | | | We need to relax constraints on invariant loads so that they do not create fake RAW dependences. So, we do not consider invariant loads as scalar dependences in a region. During these changes, it turned out that we do not consider `llvm::Value` replacements correctly within `PPCGCodeGeneration` and `ISLNodeBuilder`. The replacements dictated by `ValueMap` were not being followed in all places. This was fixed in this commit. There is no clean way to decouple this change because this bug only seems to arise when the relaxed version of invariant load hoisting was enabled. Differential Revision: https://reviews.llvm.org/D35120 llvm-svn: 307907
* [PPCGCodeGen] Differentiate kernels based on their parent ScopSingapuram Sanjay Srivallabh2017-07-121-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Add a sequence number that identifies a ptx_kernel's parent Scop within a function to it's name to differentiate it from other kernels produced from the same function, yet different Scops. Kernels produced from different Scops can end up having the same name. Consider a function with 2 Scops and each Scop being able to produce just one kernel. Both of these kernels have the name "kernel_0". This can lead to the wrong kernel being launched when the runtime picks a kernel from its cache based on the name alone. This patch supplements D33985, by differentiating kernels across Scops as well. Previously (even before D33985) while profiling kernels generated through JIT e.g. Julia, [[ https://groups.google.com/d/msg/polly-dev/J1j587H3-Qw/mR-jfL16BgAJ | kernels associated with different functions, and even different SCoPs within a function, would be grouped together due to the common name ]]. This patch prevents this grouping and the kernels are reported separately. Reviewers: grosser, bollu Reviewed By: grosser Subscribers: mehdi_amini, nemanjai, pollydev, kbarton Tags: #polly Differential Revision: https://reviews.llvm.org/D35176 llvm-svn: 307814
* [IslAst] Print memory accesses in AST dumpTobias Grosser2017-07-101-0/+60
| | | | | | | | | | | | | | | | | | | | When providing the option "-polly-ast-print-accesses" Polly also prints the memory accesses that are generated: #pragma known-parallel for (int c0 = 0; c0 <= 1023; c0 += 4) #pragma simd for (int c1 = c0; c1 <= c0 + 3; c1 += 1) Stmt_for_body( /* read */ &MemRef_B[0] /* write */ MemRef_A[c1] ); This makes writing and debugging memory layout transformations easier. Based on a patch contributed by Thomas Lang (ETH Zurich) llvm-svn: 307579
* [Polly] [PPCGCodeGeneration] Teach `must_kills` to kill scalars that are ↵Siddharth Bhat2017-07-061-5/+25
| | | | | | | | | | | | | | local to the scop. - By definition, we can pass something as a `kill` to PPCG if we know that no data can flow across a kill. - This is useful for more complex examples where we have scalars that are local to a scop. - If the local is only used within a scop, we are free to kill it. Differential Revision: https://reviews.llvm.org/D35045 llvm-svn: 307260
* Prefix the name of the calling host function in the name of callee GPU kernelSingapuram Sanjay Srivallabh2017-07-051-3/+11
| | | | | | | | | | | | | | | | | | | Summary: Provide more context to the name of a GPU kernel by prefixing its name with the host function that calls it. E.g. The first kernel called by `gemm` would be `FUNC_gemm_KERNEL_0`. Kernels currently follow the "kernel_#" (# = 0,1,2,3,...) nomenclature. This patch makes it easier to map host caller and device callee, especially when there are many kernels produced by Polly-ACC. Reviewers: grosser, Meinersbur, bollu, philip.pfaffe, kbarton! Reviewed By: grosser Subscribers: nemanjai, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D33985 llvm-svn: 307173
* [PPCGCodeGeneration] Teach Polly to start using live range reordering.Siddharth Bhat2017-07-051-6/+124
| | | | | | | | | | | | | | | | | | | | Polly did not use PPCG's live range reordering feature. Teach PPCGCodeGeneration to use this. Documentation on this is sparse, so much of the code is conservative. We currently kill all phi nodes in a Scop by appending them to the must_kill map we pass to PPCG. I do not have a proof of correctness, but it seems to be intuitively correct. We also do not handle `array_order`, which, quoting PPCG, is: PPCG/gpu.h: "Order dependences on non-scalars." It seems to consist of RAW dependences between arrays. We need to pass this information for more complex privatization cases. Differential Revision: https://reviews.llvm.org/D34941 llvm-svn: 307163
* Introduce a hybrid target to generate code for either the GPU or CPUSingapuram Sanjay Srivallabh2017-06-303-1/+12
| | | | | | | | | | | | | | | | | | | | | Summary: Introduce a "hybrid" `-polly-target` option to optimise code for either the GPU or CPU. When this target is selected, PPCGCodeGeneration will attempt first to optimise a Scop. If the Scop isn't modified, it is then sent to the passes that form the CPU pipeline, i.e. IslScheduleOptimizerPass, IslAstInfoWrapperPass and CodeGeneration. In case the Scop is modified, it is marked to be skipped by the subsequent CPU optimisation passes. Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser Subscribers: kbarton, nemanjai, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D34054 llvm-svn: 306863
* Heap allocation for new arrays.Michael Kruse2017-06-282-9/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC][CodeGen] Use the ExitBlock explicitly.Andreas Simbuerger2017-06-271-4/+2
| | | | | | | | | | | | Before we would 'guess' the correct location for the MergeBlock that got introduced when executing a Scop conditionally. This implicitly depends on the situation that at this point during CodeGen there will be nothing between polly.start and polly.exiting. With this commit we explicitly state that we want the block that directly follows polly.exiting. llvm-svn: 306398
* [PPCGCodeGeneration] Add flag to allow polly to fail in GPU kernel fails.Siddharth Bhat2017-06-261-0/+15
| | | | | | - This is useful for debugging GPU code. llvm-svn: 306290
* [PPCGCodeGeneration] Allow intrinsics within kernels.Siddharth Bhat2017-06-261-20/+125
| | | | | | | | | | | | | | | | | | | - In D33414, if any function call was found within a kernel, we would bail out. - This is an over-approximation. This patch changes this by allowing the `llvm.sqrt.*` family of intrinsics. - This introduces an additional step when creating a separate llvm::Module for a kernel (GPUModule). We now copy function declarations from the original module to new module. - We also populate IslNodeBuilder::ValueMap so it replaces the function references to the old module to the ones in the new module (GPUModule). Differential Revision: https://reviews.llvm.org/D34145 llvm-svn: 306284
* [NFC] Return both polly.start and polly.exiting from executeScopConditionally.Andreas Simbuerger2017-06-263-6/+9
| | | | | | | | | | | | | | 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
* [PPCGCodeGeneration] Enable GPU code generation with invariant loads.Siddharth Bhat2017-06-251-4/+0
| | | | | | | | | | The condition that disallowed code generation in PPCGCodeGeneration with invariant loads is not required. I haven't been able to construct a counterexample where this generates invalid code. Differential Revision: https://reviews.llvm.org/D34604 llvm-svn: 306245
* [CodeGen] Emit aliasing metadata for new arrays.Michael Kruse2017-06-192-3/+8
| | | | | | | | | | | | 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] [PPCGCodeGeneration] Skip Scops which contain function pointers.Siddharth Bhat2017-06-121-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In `PPCGCodeGeneration`, we try to take the references of every `Value` that is used within a Scop to offload to the kernel. This occurs in `GPUNodeBuilder::createLaunchParameters`. This breaks if one of the values is a function pointer, since one of these cases will trigger: 1. We try to to take the references of an intrinsic function, and this breaks at `verifyModule`, since it is illegal to take the reference of an intrinsic. 2. We manage to take the reference to a function, but this fails at `verifyModule` since the function will not be present in the module that is created in the kernel. 3. Even if `verifyModule` succeeds (which should not occur), we would then try to call a *host function* from the *device*, which is illegal runtime behaviour. So, we disable this entire range of possibilities by simply not allowing function references within a `Scop` which corresponds to a kernel. However, note that this is too conservative. We *can* allow intrinsics within kernels if the backend can lower the intrinsic correctly. For example, an intrinsic like `llvm.powi.*` can actually be lowered by the `NVPTX` backend. We will now gradually whitelist intrinsics which are known to be safe. Differential Revision: https://reviews.llvm.org/D33414 llvm-svn: 305185
* Fix a lot of typos. NFC.Michael Kruse2017-06-089-27/+27
| | | | llvm-svn: 304974
* [Polly] [BlockGen] Support partial writes in regionsTobias Grosser2017-06-061-35/+46
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The RegionGenerator traditionally kept a BlockMap that mapped from original basic blocks to newly generated basic blocks. With the introduction of partial writes such a 1:1 mapping is not possible any more, as a single basic block can be code generated into multiple basic blocks. Hence, depending on the use case we need to either use the first basic block or the last basic block. This is intended to address the last four cases of incorrect code generation in our AOSP buildbot and hopefully should turn it green. Reviewers: Meinersbur, bollu, gareevroman, efriedma, huihuiz, sebpop, simbuerg Reviewed By: Meinersbur Subscribers: pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D33767 llvm-svn: 304808
* [CodeGen] Remove extra ';'. NFC.Michael Kruse2017-06-061-1/+1
| | | | | | | | | | Fix compiler warning: polly/lib/CodeGen/PerfMonitor.cpp:81:2: warning: extra ‘;’ [-Wpedantic] }; ^ llvm-svn: 304802
* [CodeGen] Track trip counts per-scop for performance measurement.Siddharth Bhat2017-06-021-6/+20
| | | | | | | | | | | | | | | | | | | - Add a counter that is incremented once on exit from a scop. - Test cases got split into two: one to test the cycles, and another one to test trip counts. - Sample output: ```name=sample-output.txt scop function, entry block name, exit block name, total time, trip count warmup, %entry.split, %polly.merge_new_and_old, 5180, 1 f, %entry.split, %polly.merge_new_and_old, 409944, 500 g, %entry.split, %polly.merge_new_and_old, 1226, 1 ``` Differential Revision: https://reviews.llvm.org/D33822 llvm-svn: 304543
* [CodeGen] Print performance counter information in CSV.Siddharth Bhat2017-06-021-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | This ensures that tools can parse performance information which Polly generates easily. - Sample output: ```name=out.csv scop function, entry block name, exit block name, total time warmup, %entry.split, %polly.merge_new_and_old, 1960 f, %entry.split, %polly.merge_new_and_old, 1238 g, %entry.split, %polly.merge_new_and_old, 1218 ``` - Example code to parse output: ```lang=python, name=example-parse.py import asciitable import sys table = asciitable.read('out.csv', delimiter=',') asciitable.write(table, sys.stdout, delimiter=',') ``` llvm-svn: 304533
* [NFC] [CodeGen] Bail out of per-scop performance reporting if not supported.Siddharth Bhat2017-06-021-0/+8
| | | | | | | | | | We should bail out if performance monitoring is not supported, since we would have no information to print per-scop, and `FinalStartBB`, `ReturnFromFinal` would be `nullptr`. Assert that these are not `nullptr` if performance monitoring is supported. llvm-svn: 304529
* [CodeGen] Extend Performance Counter to track per-scop information.Siddharth Bhat2017-06-022-28/+75
| | | | | | | | | | | | | | | Previously, we would generate one performance counter for all scops. Now, we generate both the old information, as well as a per-scop performance counter to generate finer grained information. This patch needed a way to generate a unique name for a `Scop`. The start region, end region, and function name combined provides a unique `Scop` name. So, `Scop` has a new public API to provide its start and end region names. Differential Revision: https://reviews.llvm.org/D33723 llvm-svn: 304528
* [CodeGen] Iterate over explicit instruction list for block statements. NFCMichael Kruse2017-06-021-2/+6
| | | | | | | | | | | | For when statements do not contain all instructions of a BasicBlock anymore, the block generator needs to go through the explicit list of instructions it contains. Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in> Differential Revision: https://reviews.llvm.org/D33653 llvm-svn: 304502
* [BlockGenerator] Take context into account when identifying partial writesTobias Grosser2017-06-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | A partial write is a write where the domain of the values written is a subset of the execution domain of the parent statement containing the write. Originally, we directly checked this subset relation whereas it is indeed only important that the subset relation holds for the parameter values that are known to be valid in the execution context of the scop. We update our check to avoid the unnecessary introduction of partial writes in situations where the write appears to be partial without context information, but where context information allows us to understand that a full write can be generated. This change fixes (hides) a recent regression introduced in r303517, which broke our AOSP builds. The part that is correctly fixed in this change is that we do not any more unnecessarily generate a partial write. This is good performance wise and, as we currently do not yet explicitly introduce partial writes in the default configuration, this also hides possible bugs in the partial writes implementation. The crashes that we have originally seen were caused by such a bug, where partial writes were incorrectly generated in region statements. An additional patch in a subsequent commit is needed to address this problem. Reported-by: Reported-by: Eli Friedman <efriedma@codeaurora.org> Differential Revision: https://reviews.llvm.org/D33759 llvm-svn: 304398
* [BlockGenerator] Translate buildContainsCondition to idiomatic isl C++Tobias Grosser2017-05-311-18/+11
| | | | llvm-svn: 304354
* [Polly][NewPM] Port CodeGen to the new PMPhilip Pfaffe2017-05-231-189/+206
| | | | | | | | | | | | | | | | Summary: To move CG to the new PM I outlined the various helper that were previously members of the CG class into free static functions. The CG class itself I moved into a header, which is required because we need to include it in `RegisterPasses` eventually. Reviewers: grosser, Meinersbur Reviewed By: grosser Subscribers: pollydev, llvm-commits, sanjoy Tags: #polly Differential Revision: https://reviews.llvm.org/D33423 llvm-svn: 303624
* [Polly][NewPM] Port IslAst to the new ScopPassManagerPhilip Pfaffe2017-05-233-57/+75
| | | | | | | | | | | | | | | | Summary: This patch ports IslAst to the new PM. The change is mostly straightforward. The only major modification required is making IslAst move-only, to correctly manage the isl resources it owns. Reviewers: grosser, Meinersbur Reviewed By: grosser Subscribers: nemanjai, pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D33422 llvm-svn: 303622
* [CodeGen] Add invalidation of the loop SCEVs after merge block generation.Michael Kruse2017-05-221-0/+12
| | | | | | | | | | | | | The SCEVs of loops surrounding the escape users of a merge blocks are forgotten, so that loop trip counts based on old values can be revoked. This fixes llvm.org//PR32536 Contributed-by: Baranidharan Mohan <mbdharan@gmail.com> Differential Revision: https://reviews.llvm.org/D33195 llvm-svn: 303561
OpenPOWER on IntegriCloud