GPGPU: Make sure scops with more than one array work

We use this opportunity to add a test case containing a scalar parameter.

llvm-svn: 275547

GPGPU: Free options to avoid memory leak

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.h

Instead of directly linking to ppcg's main source directory, we link to the
parent director. This allows us to access ppcg's include f

GPGPU: Shorten ppcg include paths to avoid conflict with cuda.h

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

show more ...

GPGPU: Model array access information

This allows us to derive host-device and device-host data-transfers.

llvm-svn: 275535

GPGPU: Generate an AST for the GPU-mapped schedule

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 t

GPGPU: Generate an AST for the GPU-mapped schedule

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

show more ...

GPGPU: Add dummy implementation for ast expression construction

Instead of calling to a pet function that does not return anything, we pass
our own dummy implementation to ppcg that always returns a

GPGPU: Add dummy implementation for ast expression construction

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

show more ...

GPGPU: Use a tile size of 32 by default

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

GPGPU: Use a tile size of 32 by default

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

show more ...

Fix formatting

llvm-svn: 275397

GPGPU: Map initial schedule to GPU schedule

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
th

GPGPU: Map initial schedule to GPU schedule

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

show more ...

GPGPU: Do not dump schedule by default

llvm-svn: 275395

GPGPU: compute new schedule from polly scop

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
a

GPGPU: compute new schedule from polly scop

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

show more ...

GPGPU: create default initialized PPCG scop and gpu program

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

GPGPU: create default initialized PPCG scop and gpu program

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

show more ...

Add accelerator code generation pass skeleton

Add a new pass to serve as basis for automatic accelerator mapping in Polly.
The pass structure and the analyses preserved are copied from
CodeGeneratio

Add accelerator code generation pass skeleton

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

show more ...