README

   1 Requirements:
   2
   3 - automake, autoconf, libtool
   4         (not needed when compiling a release)
   5 - pkg-config (http://www.freedesktop.org/wiki/Software/pkg-config)
   6         (not needed when compiling a release using the included isl and pet)
   7 - gmp (http://gmplib.org/)
   8 - libyaml (http://pyyaml.org/wiki/LibYAML)
   9         (only needed if you want to compile the pet executable)
  10 - LLVM/clang libraries, 2.9 or higher (http://clang.llvm.org/get_started.html)
  11         Unless you have some other reasons for wanting to use the svn version,
  12         it is best to install the latest release (3.3).
  13         For more details, see pet/README.
  14
  15 If you are installing on Ubuntu, then you can install the following packages:
  16
  17 automake autoconf libtool pkg-config libgmp3-dev libyaml-dev libclang-dev llvm
  18
  19 Note that you need at least version 3.2 of libclang-dev (ubuntu raring).
  20 Older versions of this package did not include the required libraries.
  21 If you are using an older version of ubuntu, then you need to compile and
  22 install LLVM/clang from source.
  23
  24
  25 Preparing:
  26
  27 Grab the latest release and extract it or get the source from
  28 the git repository as follows.  This process requires autoconf,
  29 automake, libtool and pkg-config.
  30
  31         git clone git://repo.or.cz/ppcg.git
  32         cd ppcg
  33         git submodule init
  34         git submodule update
  35         ./autogen.sh
  36
  37
  38 Compilation:
  39
  40         ./configure
  41         make
  42         make check
  43
  44 If you have installed any of the required libraries in a non-standard
  45 location, then you may need to use the --with-gmp-prefix,
  46 --with-libyaml-prefix and/or --with-clang-prefix options
  47 when calling "./configure".
  48
  49
  50 Using PPCG to generate CUDA or OpenCL code
  51
  52 To convert a fragment of a C program to CUDA, insert a line containing
  53
  54         #pragma scop
  55
  56 before the fragment and add a line containing
  57
  58         #pragma endscop
  59
  60 after the fragment.  To generate CUDA code run
  61
  62         ppcg --target=cuda file.c
  63
  64 where file.c is the file containing the fragment.  The generated
  65 code is stored in file_host.cu and file_kernel.cu.
  66
  67 To generate OpenCL code run
  68
  69         ppcg --target=opencl file.c
  70
  71 where file.c is the file containing the fragment.  The generated code
  72 is stored in file_host.c and file_kernel.cl.
  73
  74
  75 Specifying tile, grid and block sizes
  76
  77 The iterations space tile size, grid size and block size can
  78 be specified using the --sizes option.  The argument is a union map
  79 in isl notation mapping kernels identified by their sequence number
  80 in a "kernel" space to singleton sets in the "tile", "grid" and "block"
  81 spaces.  The sizes are specified outermost to innermost.
  82
  83 The dimension of the "tile" space indicates the (maximal) number of loop
  84 dimensions to tile.  The elements of the single integer tuple
  85 specify the tile sizes in each dimension.
  86
  87 The dimension of the "grid" space indicates the (maximal) number of block
  88 dimensions in the grid.  The elements of the single integer tuple
  89 specify the number of blocks in each dimension.
  90
  91 The dimension of the "block" space indicates the (maximal) number of thread
  92 dimensions in the grid.  The elements of the single integer tuple
  93 specify the number of threads in each dimension.
  94
  95 For example,
  96
  97     { kernel[0] -> tile[64,64]; kernel[i] -> block[16] : i != 4 }
  98
  99 specifies that in kernel 0, two loops should be tiled with a tile
 100 size of 64 in both dimensions and that all kernels except kernel 4
 101 should be run using a block of 16 threads.
 102
 103 Since PPCG performs some scheduling, it can be difficult to predict
 104 what exactly will end up in a kernel.  If you want to specify
 105 tile, grid or block sizes, you may want to run PPCG first with the defaults,
 106 examine the kernels and then run PPCG again with the desired sizes.
 107 Instead of examining the kernels, you can also specify the option
 108 --dump-sizes on the first run to obtain the effectively used default sizes.
 109
 110
 111 Compiling the generated CUDA code with nvcc
 112
 113 To get optimal performance from nvcc, it is important to choose --arch
 114 according to your target GPU.  Specifically, use the flag "--arch sm_20"
 115 for fermi, "--arch sm_30" for GK10x Kepler and "--arch sm_35" for
 116 GK110 Kepler.  We discourage the use of older cards as we have seen
 117 correctness issues with compilation for older architectures.
 118 Note that in the absence of any --arch flag, nvcc defaults to
 119 "--arch sm_13". This will not only be slower, but can also cause
 120 correctness issues.
 121 If you want to obtain results that are identical to those obtained
 122 by the original code, then you may need to disable some optimizations
 123 by passing the "--fmad=false" option.
 124
 125
 126 Compiling the generated OpenCL code with gcc
 127
 128 To compile the host code you need to link against the file
 129 ocl_utilities.c which contains utility functions used by the generated
 130 OpenCL host code.  To compile the host code with gcc, run
 131
 132   gcc -std=c99 file_host.c ocl_utilities.c -lOpenCL
 133
 134 Note that we have experienced the generated OpenCL code freezing
 135 on some inputs (e.g., the PolyBench symm benchmark) when using
 136 at least some version of the Nvidia OpenCL library, while the
 137 corresponding CUDA code runs fine.
 138 We have experienced no such freezes when using AMD, ARM or Intel
 139 OpenCL libraries.
 140
 141 By default, the compiled executable will need the _kernel.cl file at
 142 run time.  Alternatively, the option --opencl-embed-kernel-code may be
 143 given to place the kernel code in a string literal.  The kernel code is
 144 then compiled into the host binary, such that the _kernel.cl file is no
 145 longer needed at run time.  Any kernel include files, in particular
 146 those supplied using --opencl-include-file, will still be required at
 147 run time.
 148
 149
 150 Function calls
 151
 152 Function calls inside the analyzed fragment are reproduced
 153 in the CUDA or OpenCL code, but for now it is left to the user
 154 to make sure that the functions that are being called are
 155 available from the generated kernels.
 156
 157 In the case of OpenCL code, the --opencl-include-file option
 158 may be used to specify one or more files to be #include'd
 159 from the generated code.  These files may then contain
 160 the definitions of the functions being called from the
 161 program fragment.  If the pathnames of the included files
 162 are relative to the current directory, then you may need
 163 to additionally specify the --opencl-compiler-options=-I.
 164 to make sure that the files can be found by the OpenCL compiler.
 165 The included files may contain definitions of types used by the
 166 generated kernels.  By default, PPCG generates definitions for
 167 types as needed, but these definitions may collide with those in
 168 the included files, as PPCG does not consider the contents of the
 169 included files.  The --no-opencl-print-kernel-types will prevent
 170 PPCG from generating type definitions.
 171
 172
 173 Processing PolyBench
 174
 175 When processing a PolyBench/C 3.2 benchmark, you should always specify
 176 -DPOLYBENCH_USE_C99_PROTO on the ppcg command line.  Otherwise, the source
 177 files are inconsistent, having fixed size arrays but parametrically
 178 bounded loops iterating over them.
 179 However, you should not specify this define when compiling
 180 the PPCG generated code using nvcc since CUDA does not support VLAs.
 181
 182
 183 CUDA and function overloading
 184
 185 While CUDA supports function overloading based on the arguments types,
 186 no such function overloading exists in the input language C.  Since PPCG
 187 simply prints out the same function name as in the original code, this
 188 may result in a different function being called based on the types
 189 of the arguments.  For example, if the original code contains a call
 190 to the function sqrt() with a float argument, then the argument will
 191 be promoted to a double and the sqrt() function will be called.
 192 In the transformed (CUDA) code, however, overloading will cause the
 193 function sqrtf() to be called.  Until this issue has been resolved in PPCG,
 194 we recommend that users either explicitly call the function sqrtf() or
 195 explicitly cast the argument to double in the input code.
 196
 197
 198 Contact
 199
 200 For bug reports, feature requests and questions,
 201 contact http://groups.google.com/group/isl-development
 202
 203
 204 Citing PPCG
 205
 206 If you use PPCG for your research, you are invited to cite
 207 the following paper.
 208
 209 @article{Verdoolaege2013PPCG,
 210     author = {Verdoolaege, Sven and Juega, Juan Carlos and Cohen, Albert and
 211                 G\'{o}mez, Jos{\'e} Ignacio and Tenllado, Christian and
 212                 Catthoor, Francky},
 213     title = {Polyhedral parallel code generation for CUDA},
 214     journal = {ACM Trans. Archit. Code Optim.},
 215     issue_date = {January 2013},
 216     volume = {9},
 217     number = {4},
 218     month = jan,
 219     year = {2013},
 220     issn = {1544-3566},
 221     pages = {54:1--54:23},
 222     doi = {10.1145/2400682.2400713},
 223     acmid = {2400713},
 224     publisher = {ACM},
 225     address = {New York, NY, USA},
 226 }