This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276246

This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276245

This makes the structure of the code clearer and reduces the size of runOnScop.

We also adjust the coding style to the latest LLVM style guide.

llvm-svn: 276244

This update resolves a bug in computing lexicographic minima/maxima.

llvm-svn: 276138

This fixes an issue with equality detection that resulted in an assertion
being triggered during coalescing.

llvm-svn: 276094

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

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

llvm-svn: 275962

llvm-svn: 275960

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

llvm-svn: 275956

llvm-svn: 275955

llvm-svn: 275954

llvm-svn: 275953

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

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

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

llvm-svn: 275784

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

This ensures that accidental calls to these functions will break loadly instead
of corrupting the stack with invalid return values.

These functions have been introduced earlier as replacement of pet and parts of
ppcg which we will never use and consequently have not been imported or compiled
into Polly.

llvm-svn: 275680

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

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

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

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

We do not have them in Polly and the code to check for them is directly
referring to pet data structures which we do not have available.

This commit avoids undefined behavior. As such issues are difficult to
reproduce, this commit comes without a test case.

llvm-svn: 275553

Arrays with integer base type are similar to arrays with floating point types,
with the exception that LLVM's integer types can take some odd values. We
add a selection of different values to make sure we correctly round these
types when necessary.

References to scalar integer types are special, as we currently do not model
these types as array accesses as they are considered 'synthesizable' by Polly.
As a result, we do not generate explicit data-transfers for them, but instead
will need to keep track of all references to 'synthesizable' values separately.

At the current stage, this is only visible by missing host-to-device
data-transfer calls. In the future, we will also require special code generation
strategies.

llvm-svn: 275551

We currently only test that the code structure we generate for these scalar
parameters is correct and we add these types to make sure later code generation
additions have sufficient test coverage.

In case some of these types cannot be mapped due to missing hardware support
on the GPU some of these test cases may need to be updated later on.

llvm-svn: 275548

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

llvm-svn: 275547

ppcg does not free the option structs for us. To avoid a memory leak we do this
ourselves.

llvm-svn: 275546

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

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

llvm-svn: 275535

A sequence of CHECK lines allows additional statements to appear in the
output of the tested program without any test failures appearing. As we do
not want this to happen, switch this test case to use CHECK-NEXT.

llvm-svn: 275534

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

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

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

llvm-svn: 275409

llvm-svn: 275397

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

llvm-svn: 275395

llvm-svn: 275392