summaryrefslogtreecommitdiffstats
path: root/polly/lib/Support/RegisterPasses.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Generalize the pass registration mechanism used by Polly to any third-party toolserge_sans_paille2020-01-021-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
* Add missing includes needed to prune LLVMContext.h include, NFCReid Kleckner2019-11-141-0/+1
| | | | | These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280
* Apply include-what-you-use #include removal suggestions. NFC.Michael Kruse2019-03-281-6/+0
| | | | | | | | | | | | This removes unused includes (and forward declarations) as suggested by include-what-you-use. If a transitive include of a removed include is required to compile a file, I added the required header (or forward declaration if suggested by include-what-you-use). This should reduce compilation time and reduce the number of iterative recompilations when a header was changed. llvm-svn: 357209
* Moving ManagedMemoryRewritePass when hybrid option is selectedMichael Kruse2019-03-251-4/+7
| | | | | | | | | | | | | | | Compiling with -polly-target=hybrid was causing Polly to occur two times in the pipeline. The reason was how the ManagedMemoryRewritePass was registered in the pass manager. ManagedMemoryRewritePass being a ModulePass was forcing all previous passes to get recomputed. This commit avoids Polly to appear two times in the pipeline registering the ManagedMemoryRewritePass later in the pass manager. Patch by Lorenzo Chelini <l.chelini@icloud.com> Differential Revision: https://reviews.llvm.org/D59263 llvm-svn: 356965
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [polly] Drop nonexistant LLVM_PLUGIN_EXPORT macro from llvmGetPassPluginInfo()Roman Lebedev2018-05-191-1/+1
| | | | | | | | | | | | Fixes build: /build/polly/lib/Support/RegisterPasses.cpp:709:80: error: expected ';' after top level declarator extern "C" ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK LLVM_PLUGIN_EXPORT ^ ; Was missed in rL332796 / D47082 llvm-svn: 332814
* [NewPM] Update pass registration for the LLVM plugin interfacePhilip Pfaffe2018-04-171-0/+8
| | | | | | | | | | | | | | | | Summary: As of rL329273, LLVM has a mechanism to load new-pm plugins in opt. Use this API in Polly. Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser, Meinersbur Subscribers: lksbhm, bollu, pollydev, llvm-commits Differential Revision: https://reviews.llvm.org/D45484 llvm-svn: 330181
* Add more statistics.Michael Kruse2017-08-231-2/+2
| | | | | | | | | | | | | | | | Add statistics about - Which optimizations are applied - Number of loops in Scops at various stages - Number of scalar/singleton writes at various stages representative for scalar false dependencies - Number of parallel loops These will be useful to find regressions due to moving Polly further down of LLVM's pass pipeline. Differential Revision: https://reviews.llvm.org/D37049 llvm-svn: 311553
* [ScopInliner] Add a simple Scop-based inliner to polly.Siddharth Bhat2017-08-171-0/+1
| | | | | | | | | | | | | We add a ScopInliner pass which inlines functions based on a simple heuristic: Let `g` call `f`. If we can model all of `f` as a Scop, we inline `f` into `g`. This requires `-polly-detect-full-function` to be enabled. So, the pass asserts that `-polly-detect-full-function` is enabled. Differential Revision: https://reviews.llvm.org/D36832 llvm-svn: 311126
* Add rewrite by-reference parameter passTobias Grosser2017-08-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This pass detangles induction variables from functions, which take variables by reference. Most fortran functions compiled with gfortran pass variables by reference. Unfortunately a common pattern, printf calls of induction variables, prevent in this situation the promotion of the induction variable to a register, which again inhibits any kind of loop analysis. To work around this issue we developed a specialized pass which introduces separate alloca slots for known-read-only references, which indicate the mem2reg pass that the induction variables can be promoted to registers and consquently enable SCEV to work. We currently hardcode the information that a function _gfortran_transfer_integer_write does not read its second parameter, as dragonegg does not add the right annotations and we cannot change old dragonegg releases. Hopefully flang will produce the right annotations. Reviewers: Meinersbur, bollu, singam-sanjay Reviewed By: bollu Subscribers: mgorny, pollydev, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D36800 llvm-svn: 311066
* [JSON][PM] Port json import/export over to new pmPhilip Pfaffe2017-08-101-1/+3
| | | | | | | | | | | | | | | | Summary: I pulled out all functionality into static functions, and use those both in the legacy passes and in the new ones. Reviewers: grosser, Meinersbur, bollu Reviewed By: Meinersbur Subscribers: llvm-commits, pollydev Differential Revision: https://reviews.llvm.org/D36578 llvm-svn: 310597
* [ManagedMemoryRewrite] Introduce a new pass to rewrite modules to use ↵Siddharth Bhat2017-08-091-2/+8
| | | | | | | | | | | | | | | | managed memory. This pass is useful to automatically convert a codebase that uses malloc/free to use their managed memory counterparts. Currently, rewrite malloc and free to the `polly_{malloc,free}Managed` variants. A future patch will teach ManagedMemoryRewrite to rewrite global arrays as pointers to globally allocated managed memory. Differential Revision: https://reviews.llvm.org/D36513 llvm-svn: 310471
* [RegisterPasses] Run polly-simplify also right after scop modelingTobias Grosser2017-08-081-0/+2
| | | | | | | | This allows us to get rid of stores that are overwritten within the very same basic block, without ever being read beforehand. This simplification is necessary for delicm to run on pb4's correlation. llvm-svn: 310369
* Change Polly's position to "before-vectorizer"Tobias Grosser2017-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | Polly has traditionally always been executed at the beginning of the pass pipeline as LLVM's inliner and DeLICM passes introduced plenty of scalar dependences which prevented any kind of useful high-level loop optimizations later in the pass pipeline. With DeLICM now being available, Polly can also run optimizations when folded into the pass pipeline. This has the benefit that Polly should now be more effective on C++ code and as an additional bonus, no additional early canonicalization phase must be run. As a result, Polly touches the code only if it applies a transformation. Code that does not benefit from Polly is not touched and consequently will have the very same execution time as without Polly enabled. Random performance changes, as could sometimes be observed with polly-position=early are consequently not possible any more. If performance is changed, this is due to Polly is choosing to perform a transformation. If this choice is wrong, it can be fixed directly in Polly. http://polly.llvm.org/docs/Architecture.html#polly-in-the-llvm-pass-pipeline llvm-svn: 310319
* Enable delicm to automatically remove scalar loop carried dependencesTobias Grosser2017-08-071-1/+1
| | | | | | | While this code is still rather we enable it by default to get better test coverage. llvm-svn: 310313
* [Polly] Fully-Indexed static expansionAndreas Simbuerger2017-08-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the initial version of fully-indexed static expansion. ``` for(int i = 0; i<Ni; i++) for(int j = 0; j<Ni; j++) S: B[j] = j; T: A[i] = B[i] ``` After the pass, we want this : ``` for(int i = 0; i<Ni; i++) for(int j = 0; j<Ni; j++) S: B[i][j] = j; T: A[i] = B[i][i] ``` For now we bail (fail) in the following cases: - Scalar access - Multiple writes per SAI - MayWrite Access - Expansion that leads to an access to the original array Furthermore: We still miss checks for escaping references to the array base pointers. A future commit will add the missing escape-checks to stay correct in those cases. The expansion is still locked behind a CLI-Option and should not yet be used. Patch contributed by: Nicholas Bonfante <bonfante.nicolas@gmail.com> Reviewers: simbuerg, Meinersbur, bollu Reviewed By: Meinersbur Subscribers: mgorny, llvm-commits, pollydev Differential Revision: https://reviews.llvm.org/D34982 llvm-svn: 310304
* Enable simplify and forward-op-tree by defaultTobias Grosser2017-08-021-2/+2
| | | | | | | | | These passes have been tested over the last month and should generally help to remove scalar data dependences in Polly. We enable them to give them even wider test coverage. Large performance regressions and any kind of correctness regressions are not expected. llvm-svn: 309878
* Replace asserts with llvm_unreachable to clarify intentTobias Grosser2017-08-021-2/+2
| | | | llvm-svn: 309856
* [Polly][PM][WIP] Polly pass registrationPhilip Pfaffe2017-08-021-0/+203
| | | | | | | | | | | | | | | | | | | | | Summary: This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools. This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them. My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them? Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser Subscribers: llvm-commits, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D35458 llvm-svn: 309826
* [ForwardOpTree] Introduce the -polly-optree pass.Michael Kruse2017-07-221-0/+9
| | | | | | | | | | | | | | | | | | This pass 'forwards' operand trees into statements that use them in order to avoid scalar dependencies. This minimal implementation handles only the case of speculatable instructions. We will successively add support for: - Hoisted loads - Read-only values - Synthesizable values - Loads - PHIs - Forwarding only parts of the tree Differential Revision: https://reviews.llvm.org/D35754 llvm-svn: 308825
* [Polly][GPGPU] Added SPIR Code Generation and Corresponding Runtime Support ↵Philipp Schaad2017-07-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] [RegisterPasses] Fix typo: To early -> too early.Siddharth Bhat2017-07-211-1/+1
| | | | llvm-svn: 308743
* Introduce a hybrid target to generate code for either the GPU or CPUSingapuram Sanjay Srivallabh2017-06-301-13/+16
| | | | | | | | | | | | | | | | | | | | | 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
* Initializing NVPTX backend within PollySingapuram Sanjay Srivallabh2017-06-291-0/+5
| | | | | | | | | | | | | | | | | Summary: The NVPTX backend is now initialised within Polly. A language front-end need not be modified to initialise the backend, just for Polly. Reviewers: Meinersbur, grosser Reviewed By: Meinersbur Subscribers: vchuravy, mgorny Tags: #polly Differential Revision: https://reviews.llvm.org/D31859 llvm-svn: 306649
* [PPCGCodeGeneration] Enable GPU code generation with invariant loads.Siddharth Bhat2017-06-251-5/+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
* [NFC] Fix typo in `ImportJScop` declaration.Siddharth Bhat2017-06-121-1/+1
| | | | | | | | Contributed by: Singapuram Sanjay Differential Revision: https://reviews.llvm.org/D34079 llvm-svn: 305183
* Revert "[NFC] Fix formatting & typecast issue. Build succeeds."Siddharth Bhat2017-05-291-1/+1
| | | | | | | | Should not have 'fixed' the formatting issue, I did not have the most recent version of `clang-format`. This reverts commit 761b1268359e14e59142f253d77864a29d55c56c. llvm-svn: 304148
* [NFC] Fix formatting & typecast issue. Build succeeds.Siddharth Bhat2017-05-291-1/+1
| | | | | | | | | - Fix formatting in `RegisterPasses.cpp`. - `assert` tried to compare `isl::boolean` against `long`. Explicitly construct `bool` from `isl::boolean`. This allows the implicit cast of `bool` to `long. llvm-svn: 304146
* Adapt to recent clang-format changesTobias Grosser2017-05-291-1/+1
| | | | llvm-svn: 304136
* [Polly][NewPM] Port IslAst to the new ScopPassManagerPhilip Pfaffe2017-05-231-2/+2
| | | | | | | | | | | | | | | | 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
* Adjust formattingTobias Grosser2017-05-151-1/+1
| | | | llvm-svn: 303065
* [Polly][NewPM] Port ScopDetection to the new PassManagerPhilip Pfaffe2017-05-121-2/+2
| | | | | | | | | | | | | | | | Summary: This is a proof of concept of how to port polly-passes to the new PassManager architecture. This approach works ootb for Function-Passes, but might not be directly applicable to Scop/Region-Passes. While we could just run the Analyses/Transforms over functions instead, we'd surrender the nice pipelining behaviour we have now. Reviewers: Meinersbur, grosser Reviewed By: grosser Subscribers: pollydev, sanjoy, nemanjai, llvm-commits Tags: #polly Differential Revision: https://reviews.llvm.org/D31459 llvm-svn: 302902
* [Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGenSiddharth Bhat2017-05-071-1/+20
| | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling for GPU, one can now choose to compile for OpenCL or CUDA, with the corresponding polly-gpu-runtime flag (libopencl / libcudart). The GPURuntime library (GPUJIT) has been extended with the OpenCL Runtime library for that purpose, correctly choosing the corresponding library calls to the option chosen when compiling (via different initialization calls). Additionally, a specific GPU Target architecture can now be chosen with -polly-gpu-arch (only nvptx64 implemented thus far). Reviewers: grosser, bollu, Meinersbur, etherzhhb, singam-sanjay Reviewed By: grosser, Meinersbur Subscribers: singam-sanjay, llvm-commits, pollydev, nemanjai, mgorny, yaxunl, Anastasia Tags: #polly Differential Revision: https://reviews.llvm.org/D32431 llvm-svn: 302379
* Revert "[Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGen"Siddharth Bhat2017-05-051-20/+1
| | | | | | | | | | | | | | | This reverts commit 17a84e414adb51ee375d14836d4c2a817b191933. Patches should have been submitted in the order of: 1. D32852 2. D32854 3. D32431 I mistakenly pushed D32431(3) first. Reverting to push in the correct order. llvm-svn: 302217
* [Polly] Added OpenCL Runtime to GPURuntime Library for GPGPU CodeGenSiddharth Bhat2017-05-051-1/+20
| | | | | | | | | | | | | | | | | | | | | | | Summary: When compiling for GPU, one can now choose to compile for OpenCL or CUDA, with the corresponding polly-gpu-runtime flag (libopencl / libcudart). The GPURuntime library (GPUJIT) has been extended with the OpenCL Runtime library for that purpose, correctly choosing the corresponding library calls to the option chosen when compiling (via different initialization calls). Additionally, a specific GPU Target architecture can now be chosen with -polly-gpu-arch (only nvptx64 implemented thus far). Reviewers: grosser, bollu, Meinersbur, etherzhhb, singam-sanjay Reviewed By: grosser, Meinersbur Subscribers: singam-sanjay, llvm-commits, pollydev, nemanjai, mgorny, yaxunl, Anastasia Tags: #polly Differential Revision: https://reviews.llvm.org/D32431 llvm-svn: 302215
* [ScopInfo/PruneUnprofitable] Move default profitability check.Michael Kruse2017-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | In the previous default ScopInfo applied the profitability heuristic for scalar accesses (-polly-unprofitable-scalar-accs=true) and the -polly-prune-unprofitable was disabled by default (-polly-enable-prune-unprofitable=false) as that pruning was already done. This changes switches the defaults to -polly-unprofitable-scalar-accs=true -polly-enable-prune-unprofitable=false such that the scalar access heuristic check is done by the pass. This allows passes between ScopInfo and PruneUnprofitable to optimize away scalar accesses. Without enabling such intermediate passes, there is no change in behaviour of profitability checks in a PassManagerBuilder built pass chain, but it allows us to cover this configuration with the buildbots. Suggested-by: Tobias Grosser <tobias@grosser.es> llvm-svn: 298081
* [PruneUnprofitable] Add -polly-prune-unprofitable pass.Michael Kruse2017-03-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | ScopInfo's normal profitability heuristic considers SCoPs where all statements have scalar writes as not profitably optimizable and invalidate the SCoP in that case. However, -polly-delicm and -polly-simplify may be able to remove some of the scalar writes such that the flag -polly-unprofitable-scalar-accs=false allows disabling that part of the heuristic. In cases where DeLICM (or other passes after ScopInfo) are not successful in removing scalar writes, the SCoP is still not profitably optimizable. The schedule optimizer would again try computing another schedule, resulting in slower compilation. The -polly-prune-unprofitable pass applies the profitability heuristic again before the schedule optimizer Polly can still bail out even with -polly-unprofitable-scalar-accs=false. Differential Revision: https://reviews.llvm.org/D31033 llvm-svn: 298080
* [Simplify] Add -polly-simplify pass.Michael Kruse2017-03-101-0/+9
| | | | | | | | | | | | | | | | | This new pass removes unnecessary accesses and writes. It currently supports 2 simplifications, but more are planned. It removes write accesses that write a loaded value back to the location it was loaded from. It is a typical artifact from DeLICM. Removing it will get rid of bogus dependencies later in dependency analysis. It also removes statements without side-effects. ScopInfo already removes these, but the removal of unnecessary writes can result in more side-effect free statements. Differential Revision: https://reviews.llvm.org/D30820 llvm-svn: 297473
* [Support] Add -polly-dump-module pass.Michael Kruse2017-03-091-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass allows writing the LLVM-IR just before and after the Polly passes to a file. Dumping the IR before Polly helps reproducing bugs that occur in code generated by clang. It is the only reliable way to get the IR that triggers a bug. The alternative is to emit the IR with clang -c -emit-llvm -S -o dump.ll then pass it through all optimization passes opt dump.ll -basicaa -sroa ... -S -o optdump.ll to then reproduce the error with opt optdump.ll -polly-opt-isl -polly-codegen -analyze However, the IR is not the same. -O3 uses a PassBuilder than creates passes with different parameters than the default. Dumping the IR after Polly is useful to compare a miscompilation with a known-good configuration. Differential Revision: https://reviews.llvm.org/D30788 llvm-svn: 297415
* [DeLICM] Add pass boilerplate code.Michael Kruse2016-11-291-0/+10
| | | | | | | | | | Add an empty DeLICM pass, without any functional parts. Extracting the boilerplate from the the functional part reduces the size of the code to review (https://reviews.llvm.org/D24716) Suggested-by: Tobias Grosser <tobias@grosser.es> llvm-svn: 288160
* Fix formatting after recent cl:: changesTobias Grosser2016-10-091-10/+13
| | | | | | This fixes 'make check-polly' llvm-svn: 283693
* Turn cl::values() (for enum) from a vararg function to using C++ variadic ↵Mehdi Amini2016-10-081-11/+7
| | | | | | | | | | | | | | | template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
* Update CFGPrinter -> CFGPrinterLegacyPassTobias Grosser2016-09-161-1/+1
| | | | | | .. to match recent changes in LLVM that broke the Polly compilation. llvm-svn: 281705
* Add -polly-flatten-schedule pass.Michael Kruse2016-09-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The -polly-flatten-schedule pass reduces the number of scattering dimensions in its isl_union_map form to make them easier to understand. It is not meant to be used in production, only for debugging and regression tests. To illustrate, how it can make sets simpler, here is a lifetime set used computed by the porposed DeLICM pass without flattening: { Stmt_reduction_for[0, 4] -> [0, 2, o2, o3] : o2 < 0; Stmt_reduction_for[0, 4] -> [0, 1, o2, o3] : o2 >= 5; Stmt_reduction_for[0, 4] -> [0, 1, 4, o3] : o3 > 0; Stmt_reduction_for[0, i1] -> [0, 1, i1, 1] : 0 <= i1 <= 3; Stmt_reduction_for[0, 4] -> [0, 2, 0, o3] : o3 <= 0 } And here the same lifetime for a semantically identical one-dimensional schedule: { Stmt_reduction_for[0, i1] -> [2 + 3i1] : 0 <= i1 <= 4 } Differential Revision: https://reviews.llvm.org/D24310 llvm-svn: 280948
* Introduce option to run isl AST generation, but no IR generation.Tobias Grosser2016-09-021-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | We replace the options -polly-code-generator=none =isl with the options -polly-code-generation=none =ast =full This allows us to measure the overhead of Polly itself, versus the compile time increases due to us generating more IR and consequently the LLVM backends spending more time on this IR. We also use this opportunity to rename the option. The original name was introduced at a point where we still had two code generators. CLooG and the isl AST generator. Since we only have one AST generator left, there is no need to distinguish between 'isl' and something else. However, being able to disable code generation all together has been shown useful for debugging. Hence, we rename and extend this option to make it a good fit for its new use case. llvm-svn: 280554
* Drop '@brief' from doxygen commentsTobias Grosser2016-09-021-2/+2
| | | | | | | | LLVM's coding guideline suggests to not use @brief for one-sentence doxygen comments to improve readability. Switch this once and for all to ensure people do not copy @brief comments from other parts of Polly, when writing new code. llvm-svn: 280468
* [GSoC] Add PolyhedralInfo pass - new interface to polly analysisJohannes Doerfert2016-07-251-0/+9
| | | | | | | | | | | | | Adding a new pass PolyhedralInfo. This pass will be the interface to Polly. Initially, we will provide the following interface: - #IsParallel(Loop *L) - return a bool depending on whether the loop is parallel or not for the given program order. Patch by Utpal Bora <cs14mtech11017@iith.ac.in> Differential Revision: https://reviews.llvm.org/D21486 llvm-svn: 276637
* GPGPU: Disable invariant load hoisting for GPU code generationTobias Grosser2016-07-191-0/+5
| | | | | | | | This simplifies the upcoming patches to add code generation for ScopStmts. Load hoisting support will later be added in a separate commit. This commit will be implicitly tested by the subsequent GPGPU changes. llvm-svn: 275969
* PPCGCodegen: Support compilation without GPU supportTobias Grosser2016-07-131-0/+7
| | | | llvm-svn: 275310
* Add accelerator code generation pass skeletonTobias Grosser2016-07-131-13/+30
| | | | | | | | | | | | | | | | | | | | | | | Add a new pass to serve as basis for automatic accelerator mapping in Polly. The pass structure and the analyses preserved are copied from CodeGeneration.cpp, as we will rely on IslNodeBuilder and IslExprBuilder for LLVM-IR code generation. Polly's accelerator code generation is enabled with -polly-target=gpu I would like to use this commit as opportunity to thank Yabin Hu for his work in the context of two Google summer of code projects during which he implemented initial prototypes of the Polly accelerator code generation -- in parts this code is already available in todays Polly (e.g., tools/GPURuntime). More will come as part of the upcoming Polly ACC changes. Reviewers: Meinersbur Subscribers: pollydev, llvm-commits Differential Revision: http://reviews.llvm.org/D22036 llvm-svn: 275275
OpenPOWER on IntegriCloud