summaryrefslogtreecommitdiffstats
path: root/polly/lib/CodeGen/PPCGCodeGeneration.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* GPGPU: Add basic support for kernel launchesTobias Grosser2016-07-271-0/+171
| | | | llvm-svn: 276863
* GPGPU: Load GPU kernelsTobias Grosser2016-07-251-3/+60
| | | | | | | We embed the PTX code into the host IR as a global variable and compile it at run-time into a GPU kernel. llvm-svn: 276645
* GPGPU: Emit data-transfer codeTobias Grosser2016-07-251-25/+139
| | | | | | | Also factor out getArraySize() to avoid code dupliciation and reorder some function arguments to indicate the direction into which data is transferred. llvm-svn: 276636
* GPGPU: Complete code to allocate and free device arraysTobias Grosser2016-07-251-4/+45
| | | | | | | At the beginning of each SCoP, we allocate device arrays for all arrays used on the GPU and we free such arrays after the SCoP has been executed. llvm-svn: 276635
* GPGPU: initialize GPU context and simplify the corresponding GPURuntime ↵Tobias Grosser2016-07-251-0/+116
| | | | | | | | | interface. There is no need to expose the selected device at the moment. We also pass back pointers as return values, as this simplifies the interface. llvm-svn: 276623
* IslNodeBuilder: Make finalize() virtualTobias Grosser2016-07-251-1/+1
| | | | | | | | This allows the finalization routine of the IslNodeBuilder to be overwritten by derived classes. Being here, we also drop the unnecessary 'Scop' postfix and the unnecessary 'Scop' parameter. llvm-svn: 276622
* GPGPU: Optimize kernel IR before generating assembly codeTobias Grosser2016-07-241-0/+9
| | | | | | | | We optimize the kernel _after_ dumping the IR we generate to make the IR we dump easier readable and independent of possible changes in the general purpose LLVM optimizers. llvm-svn: 276551
* GPGPU: Verify kernel IR before generating assemblyTobias Grosser2016-07-241-0/+5
| | | | llvm-svn: 276550
* GPGPU: Generate PTX assembly code for the kernel modulesTobias Grosser2016-07-221-0/+123
| | | | | | | | | | | | | | | | | Run the NVPTX backend over the GPUModule IR and write the resulting assembly code in a string. To work correctly, it is important to invalidate analysis results that still reference the IR in the kernel module. Hence, this change clears all references to dominators, loop info, and scalar evolution. Finally, the NVPTX backend has troubles to generate code for various special floating point types (not surprising), but also for uncommon integer types. This commit does not resolve these issues, but pulls out problematic test cases into separate files to XFAIL them individually and resolve them in future (not immediate) changes one by one. llvm-svn: 276396
* GPGPU: generate code for ScopStatementsTobias Grosser2016-07-211-15/+202
| | | | | | | | | | | | | | | This change introduces the actual compute code in the GPU kernels. To ensure all values referenced from the statements in the GPU kernel are indeed available we scan all ScopStmts in the GPU kernel for references to llvm::Values that are not yet covered by already modeled outer loop iterators, parameters, or array base pointers and also pass these additional llvm::Values to the GPU kernel. For arrays used in the GPU kernel we introduce a new ScopArrayInfo object, which is referenced by the newly generated access functions within the GPU kernel and which is used to help with code generation. llvm-svn: 276270
* GPGPU: Bail out of scops with hoisted invariant loadsTobias Grosser2016-07-191-0/+4
| | | | | | | This is currently not supported and will only be added later. Also update the test cases to ensure no invariant code hoisting is applied. llvm-svn: 275987
* GPGPU: Emit in-kernel synchronization statementsTobias Grosser2016-07-191-0/+49
| | | | | | | We use this opportunity to further classify the different user statements that can arise and add TODOs for the ones not yet implemented. llvm-svn: 275957
* GPGPU: generate control flow within the kernelTobias Grosser2016-07-191-0/+6
| | | | llvm-svn: 275956
* GPGPU: add scop parameters to kernel argumentsTobias Grosser2016-07-191-1/+14
| | | | llvm-svn: 275955
* GPGPU: add host iterators to kernel argumentsTobias Grosser2016-07-191-1/+14
| | | | llvm-svn: 275954
* GPGPU: add intrinsic functions to obtain a kernels thread and block idsTobias Grosser2016-07-191-0/+50
| | | | llvm-svn: 275953
* GPGPU: create kernel function skeletonTobias Grosser2016-07-191-7/+153
| | | | | | | | | Create for each kernel a separate LLVM-IR module containing a single function marked as kernel function and taking one pointer for each array referenced by this kernel. Add debugging output to verify the kernels are generated correctly. llvm-svn: 275952
* GPGPU: collect array referencesTobias Grosser2016-07-181-0/+2
| | | | | | | | | | | Initialize the list of references to a GPU array to ensure that the arrays that need to be passed to kernel calls are computed correctly. Furthermore, the very same information is also necessary to compute synchronization correctly. As the functionality to compute these references is already available, what is left for us to do is only to connect the necessary functionality to compute array reference information. llvm-svn: 275798
* GPGPU: Pull implementation out of class definitionTobias Grosser2016-07-181-4/+7
| | | | | | | This will allow us to see the full class definition even after we add non-trivial implementations of the different member functions. llvm-svn: 275797
* GPGPU: Create host control flowTobias Grosser2016-07-181-0/+82
| | | | | | | | | | | | | | Create LLVM-IR for all host-side control flow of a given GPU AST. We implement this by introducing a new GPUNodeBuilder class derived from IslNodeBuilder. The IslNodeBuilder will take care of generating all general-purpose ast nodes, but we provide our own createUser implementation to handle the different GPU specific user statements. For now, we just skip any user statement and only generate a host-code sceleton, but in subsequent commits we will add handling of normal ScopStmt's performing computations, kernel calls, as well as host-device data transfers. We will also introduce run-time check generation and LICM in subsequent commits. llvm-svn: 275783
* GPGPU: Format statements scheduled on the host ourselvesTobias Grosser2016-07-151-0/+14
| | | | | | | | Otherwise ppcg would try to call into pet functionality that this not available, which obviously will cause trouble. As we can easily print these statements ourselves, we just do so. llvm-svn: 275579
* GPGPU: Use schedule whole components for schedulerTobias Grosser2016-07-151-9/+1
| | | | | | | | | | | This option increases the scalability of the scheduler and allows us to remove the 'gisting' workaround we introduced in r275565 to handle a more complicated test case. Another benefit of using this option is also that the generated code looks a lot more streamlined. Thanks to Sven Verdoolaege for reminding me of this option. llvm-svn: 275573
* GPGPU: Drop domain constraints from flow dependencesTobias Grosser2016-07-151-0/+9
| | | | | | | | This works around a shortcoming of the isl scheduler, which even for some smaller test cases does not terminate in case domain constraints are part of the flow dependences. llvm-svn: 275565
* GPGPU: Add memory reference tag ids to tagged accessesTobias Grosser2016-07-151-0/+2
| | | | | | | | | | It seems we forgot to actually add the memory access ids to the tagged accesses, but instead just tagged the accesses with empty isl_ids. This issue was found by inspection and without code generation it is difficult to test just by itself. We fix it for now without test case and expect our code generation tests to cover this later on. llvm-svn: 275557
* GPGPU: Make sure scops with more than one array workTobias Grosser2016-07-151-0/+1
| | | | | | We use this opportunity to add a test case containing a scalar parameter. llvm-svn: 275547
* GPGPU: Free options to avoid memory leakTobias Grosser2016-07-151-0/+14
| | | | | | | ppcg does not free the option structs for us. To avoid a memory leak we do this ourselves. llvm-svn: 275546
* GPGPU: Shorten ppcg include paths to avoid conflict with cuda.hTobias Grosser2016-07-151-5/+5
| | | | | | | | | | Instead of directly linking to ppcg's main source directory, we link to the parent director. This allows us to access ppcg's include files with 'ppcg/cuda.h' and avoids a conflict with NVIDIA's cuda.h header. Also drop an include directory that is currently not used. llvm-svn: 275536
* GPGPU: Model array access informationTobias Grosser2016-07-151-10/+150
| | | | | | This allows us to derive host-device and device-host data-transfers. llvm-svn: 275535
* GPGPU: Generate an AST for the GPU-mapped scheduleTobias Grosser2016-07-141-4/+127
| | | | | | | | | | For this we need to provide an explicit list of statements as they occur in the polly::Scop to ppcg. We also setup basic AST printing facilities to facilitate debugging. To allow code reuse some (minor) changes in ppcg are have been necessary. llvm-svn: 275436
* GPGPU: Add dummy implementation for ast expression constructionTobias Grosser2016-07-141-0/+18
| | | | | | | | | | | | | Instead of calling to a pet function that does not return anything, we pass our own dummy implementation to ppcg that always returns a nullptr. This ensures that the list of ast expressions always contains a nullptr and we do not accidentally free a random (uninitalized) pointer. This resolves the last valgrind warning we see. We provide an implementation for this function, when the generated AST expressions can be used and consequently can be tested. llvm-svn: 275435
* GPGPU: Use a tile size of 32 by defaultTobias Grosser2016-07-141-0/+2
| | | | | | | | | The tile size was previously uninitialized. As a result, it was often zero (aka. no tiling), which is not what we want in general. More importantly, there was the risk for arbitrary tile sizes to be choosen, which we did not observe, but which still is highly problematic. llvm-svn: 275418
* Fix formattingTobias Grosser2016-07-141-1/+2
| | | | llvm-svn: 275397
* GPGPU: Map initial schedule to GPU scheduleTobias Grosser2016-07-141-2/+41
| | | | | | | | This change now applies ppcg's GPU mapping on our initial schedule. For this to work, we need to also initialize the set of all names (isl_ids) used in the scop as well as the program context. llvm-svn: 275396
* GPGPU: Do not dump schedule by defaultTobias Grosser2016-07-141-1/+1
| | | | llvm-svn: 275395
* GPGPU: compute new schedule from polly scopTobias Grosser2016-07-141-12/+147
| | | | | | | | | | | | | | | | | | | | To do so we copy the necessary information to compute an initial schedule from polly::Scop to ppcg's scop. Most of the necessary information is directly available and only needs to be passed on to ppcg, with the exception of 'tagged' access relations, access relations that additionally carry information about which memory access an access relation originates from. We could possibly perform the construction of tagged accesses as part of ScopInfo, but as this format is currently specific to ppcg we do not do this yet, but keep this functionality local to our GPU code generation. After the scop has been initialized, we compute data dependences and ask ppcg to compute an initial schedule. Some of this functionality is already available in polly::DependenceInfo and polly::ScheduleOptimizer, but to keep differences to ppcg small we use ppcg's functionality here. We may later investiage if a closer integration of these tools makes sense. llvm-svn: 275390
* GPGPU: create default initialized PPCG scop and gpu programTobias Grosser2016-07-141-1/+137
| | | | | | | | | | | | | | At this stage, we do not yet modify the IR but just generate a default initialized ppcg_scop and gpu_prog and free both immediately. Both will later be filled with data from the polly::Scop and are needed to use PPCG for GPU schedule generation. This commit does not yet perform any GPU code generation, but ensures that the basic infrastructure has been put in place. We also add a simple test case to ensure the new code is run and use this opportunity to verify that GPU_CODEGEN tests are only run if GPU code generation has been enabled in cmake. llvm-svn: 275389
* Add accelerator code generation pass skeletonTobias Grosser2016-07-131-0/+82
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