Move MemoryAccess::NewAccessRelation to isl++

We also move related accessor functions

llvm-svn: 308840

Move MemoryAccess::id to isl++

llvm-svn: 308836

Move ScopArrayInfo to isl++

This moves the full ScopArrayInfo class to isl++

llvm-svn: 308801

[Polly][GPGPU] Added SPIR Code Generation and Corresponding Runtime Support for Intel

Summary:
Added SPIR Code Generation to the PPCG Code Generator. This can be invoked using
the polly-gpu-arch fla

[Polly][GPGPU] Added SPIR Code Generation and Corresponding Runtime Support 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

show more ...

[NFC] [PPCGCodeGeneration] Print `verifyModule` failure to debug stream.

If verifyModule fails, it is helpful to know why it failed. Add a log to
the debug stream that prints the failure.

llvm-svn:

[NFC] [PPCGCodeGeneration] Print `verifyModule` failure to debug stream.

If verifyModule fails, it is helpful to know why it failed. Add a log to
the debug stream that prints the failure.

llvm-svn: 308727

show more ...

Fix typo in function name Bllock -> Block

llvm-svn: 308715

Support fabs and copysign in Polly-ACC

llvm-svn: 308649

[PPCGCodeGen] [3/3] Update PPCGCodeGen + tests to latest ppcg.

This commit *WILL COMPILE*.

1. `PPCG` now uses `isl_multi_pw_aff` instead of an array of `pw_aff`.
This needs us to adjust how we i

[PPCGCodeGen] [3/3] Update PPCGCodeGen + tests to latest ppcg.

This commit *WILL COMPILE*.

1. `PPCG` now uses `isl_multi_pw_aff` instead of an array of `pw_aff`.
This needs us to adjust how we index array bounds and how we construct
array bounds.

2. `PPCG` introduces two new kinds of nodes: `init_device` and `clear_device`.
We should investigate what the correct way to handle these are.

3. `PPCG` has gotten smarter with its use of live range reordering, so some of
the tests have a qualitative improvement.

4. `PPCG` changed its output style, so many test cases need to be updated to
fit the new style for `polly-acc-dump-code` checks.

Differential Revision: https://reviews.llvm.org/D35677

llvm-svn: 308625

show more ...

[NFC] [PPCGCodeGeneration] cleanup kills related code.

We extended kills in Polly to handle both `phi` nodes and scalars that
are not used within the Scop. Update the comments and choice of

[NFC] [PPCGCodeGeneration] cleanup kills related code.

We extended kills in Polly to handle both `phi` nodes and scalars that
are not used within the Scop. Update the comments and choice of
variable names to reflect this.

llvm-svn: 308279

show more ...

[PPCGCodeGeneration] Generate invariant loads before trying to generate IR.

- We should call `preloadInvariantLoads` to make sure that code is
generated for invariant loads in the kernel.

Diffe

[PPCGCodeGeneration] Generate invariant loads before trying to generate IR.

- We should call `preloadInvariantLoads` to make sure that code is
generated for invariant loads in the kernel.

Differential Revision: https://reviews.llvm.org/D35410

llvm-svn: 308187

show more ...

[PPCGCodeGeneration] Fix runtime check adjustments since they make assumptions about BB layout.

- There is a conditional branch that is used to switch between the old
and new versions of the code

[PPCGCodeGeneration] Fix runtime check adjustments since they make assumptions about BB layout.

- There is a conditional branch that is used to switch between the old
and new versions of the code.

- If we detect that the build was unsuccessful, `PPCGCodeGeneration` will
change the runtime check to be always set to false.

- To actually *reach* this runtime check instruction, `PPCGCodeGeneration`
was using assumptions about the layout of the BBs.

- However, invariant load hoisting violates this assumption by inserting
an extra basic block in the middle.

- Fix the assumption on the layout by having `createScopConditionally`
return the conditional branch instruction.

- Use this reference to set to always-false.

llvm-svn: 308010

show more ...

[Invariant Loads] Do not consider invariant loads to have dependences.

We need to relax constraints on invariant loads so that they do not
create fake RAW dependences. So, we do not consider invaria

[Invariant Loads] Do not consider invariant loads to have dependences.

We need to relax constraints on invariant loads so that they do not
create fake RAW dependences. So, we do not consider invariant loads as
scalar dependences in a region.

During these changes, it turned out that we do not consider `llvm::Value`
replacements correctly within `PPCGCodeGeneration` and `ISLNodeBuilder`.
The replacements dictated by `ValueMap` were not being followed in all
places. This was fixed in this commit. There is no clean way to decouple
this change because this bug only seems to arise when the relaxed
version of invariant load hoisting was enabled.

Differential Revision: https://reviews.llvm.org/D35120

llvm-svn: 307907

show more ...

[PPCGCodeGen] Differentiate kernels based on their parent Scop

Summary:
Add a sequence number that identifies a ptx_kernel's parent Scop within a function to it's name to differentiate it from other

[PPCGCodeGen] Differentiate kernels based on their parent Scop

Summary:
Add a sequence number that identifies a ptx_kernel's parent Scop within a function to it's name to differentiate it from other kernels produced from the same function, yet different Scops.

Kernels produced from different Scops can end up having the same name. Consider a function with 2 Scops and each Scop being able to produce just one kernel. Both of these kernels have the name "kernel_0". This can lead to the wrong kernel being launched when the runtime picks a kernel from its cache based on the name alone. This patch supplements D33985, by differentiating kernels across Scops as well.

Previously (even before D33985) while profiling kernels generated through JIT e.g. Julia, [[ https://groups.google.com/d/msg/polly-dev/J1j587H3-Qw/mR-jfL16BgAJ | kernels associated with different functions, and even different SCoPs within a function, would be grouped together due to the common name ]]. This patch prevents this grouping and the kernels are reported separately.

Reviewers: grosser, bollu

Reviewed By: grosser

Subscribers: mehdi_amini, nemanjai, pollydev, kbarton

Tags: #polly

Differential Revision: https://reviews.llvm.org/D35176

llvm-svn: 307814

show more ...

[Polly] [PPCGCodeGeneration] Teach `must_kills` to kill scalars that are local to the scop.

- By definition, we can pass something as a `kill` to PPCG if we know
that no data can flow across a kill.

[Polly] [PPCGCodeGeneration] Teach `must_kills` to kill scalars that are local to the scop.

- By definition, we can pass something as a `kill` to PPCG if we know
that no data can flow across a kill.
- This is useful for more complex examples where we have scalars that
are local to a scop.
- If the local is only used within a scop, we are free to kill it.

Differential Revision: https://reviews.llvm.org/D35045

llvm-svn: 307260

show more ...

Prefix the name of the calling host function in the name of callee GPU kernel

Summary:
Provide more context to the name of a GPU kernel by prefixing its name with the host function that calls it. E.

Prefix the name of the calling host function in the name of callee GPU kernel

Summary:
Provide more context to the name of a GPU kernel by prefixing its name with the host function that calls it. E.g. The first kernel called by `gemm` would be `FUNC_gemm_KERNEL_0`.

Kernels currently follow the "kernel_#" (# = 0,1,2,3,...) nomenclature. This patch makes it easier to map host caller and device callee, especially when there are many kernels produced by Polly-ACC.

Reviewers: grosser, Meinersbur, bollu, philip.pfaffe, kbarton!

Reviewed By: grosser

Subscribers: nemanjai, pollydev

Tags: #polly

Differential Revision: https://reviews.llvm.org/D33985

llvm-svn: 307173

show more ...

[PPCGCodeGeneration] Teach Polly to start using live range reordering.

Polly did not use PPCG's live range reordering feature. Teach
PPCGCodeGeneration to use this.

Documentation on this is sparse,

[PPCGCodeGeneration] Teach Polly to start using live range reordering.

Polly did not use PPCG's live range reordering feature. Teach
PPCGCodeGeneration to use this.

Documentation on this is sparse, so much of the code is conservative.

We currently kill all phi nodes in a Scop by appending them to the
must_kill map we pass to PPCG. I do not have a proof of correctness,
but it seems to be intuitively correct.

We also do not handle `array_order`, which, quoting PPCG, is:
PPCG/gpu.h: "Order dependences on non-scalars."
It seems to consist of RAW dependences between arrays. We need to
pass this information for more complex privatization cases.

Differential Revision: https://reviews.llvm.org/D34941

llvm-svn: 307163

show more ...

Introduce a hybrid target to generate code for either the GPU or CPU

Summary:
Introduce a "hybrid" `-polly-target` option to optimise code for either the GPU or CPU.

When this target is selected, P

Introduce a hybrid target to generate code for either the GPU or CPU

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

show more ...

[PPCGCodeGeneration] Add flag to allow polly to fail in GPU kernel fails.

- This is useful for debugging GPU code.

llvm-svn: 306290

[PPCGCodeGeneration] Allow intrinsics within kernels.

- In D33414, if any function call was found within a kernel, we would bail out.

- This is an over-approximation. This patch changes this by all

[PPCGCodeGeneration] Allow intrinsics within kernels.

- In D33414, if any function call was found within a kernel, we would bail out.

- This is an over-approximation. This patch changes this by allowing the
`llvm.sqrt.*` family of intrinsics.

- This introduces an additional step when creating a separate llvm::Module
for a kernel (GPUModule). We now copy function declarations from the
original module to new module.

- We also populate IslNodeBuilder::ValueMap so it replaces the function
references to the old module to the ones in the new module
(GPUModule).

Differential Revision: https://reviews.llvm.org/D34145

llvm-svn: 306284

show more ...

[NFC] Return both polly.start and polly.exiting from executeScopConditionally.

This commit returns both the start and the exit block that are created
by executeScopConditionally.

In a future commit

[NFC] Return both polly.start and polly.exiting from executeScopConditionally.

This commit returns both the start and the exit block that are created
by executeScopConditionally.

In a future commit we will make use of the exit block. Before we would
have to use the implicit property that there won't be any code generated
between polly.start and polly.exiting at the time of use to find the
correct block ('polly.exiting').

All usage location are semantically unchanged.

llvm-svn: 306283

show more ...

[PPCGCodeGeneration] Enable GPU code generation with invariant loads.

The condition that disallowed code generation in PPCGCodeGeneration with
invariant loads is not required. I haven't been able to

[PPCGCodeGeneration] Enable GPU code generation with invariant loads.

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

show more ...

[Polly] [PPCGCodeGeneration] Skip Scops which contain function pointers.

In `PPCGCodeGeneration`, we try to take the references of every `Value`
that is used within a Scop to offload to the kernel.

[Polly] [PPCGCodeGeneration] Skip Scops which contain function pointers.

In `PPCGCodeGeneration`, we try to take the references of every `Value`
that is used within a Scop to offload to the kernel. This occurs in
`GPUNodeBuilder::createLaunchParameters`.

This breaks if one of the values is a function pointer, since one of
these cases will trigger:

1. We try to to take the references of an intrinsic function, and this
breaks at `verifyModule`, since it is illegal to take the reference of
an intrinsic.

2. We manage to take the reference to a function, but this fails at
`verifyModule` since the function will not be present in the module that
is created in the kernel.

3. Even if `verifyModule` succeeds (which should not occur), we would
then try to call a *host function* from the *device*, which is
illegal runtime behaviour.

So, we disable this entire range of possibilities by simply not allowing
function references within a `Scop` which corresponds to a kernel.

However, note that this is too conservative. We *can* allow intrinsics
within kernels if the backend can lower the intrinsic correctly. For
example, an intrinsic like `llvm.powi.*` can actually be lowered by the `NVPTX`
backend.

We will now gradually whitelist intrinsics which are known to be safe.

Differential Revision: https://reviews.llvm.org/D33414

llvm-svn: 305185

show more ...

Fix a lot of typos. NFC.

llvm-svn: 304974

[Polly][NewPM] Port IslAst to the new ScopPassManager

Summary: This patch ports IslAst to the new PM. The change is mostly straightforward. The only major modification required is making IslAst move

[Polly][NewPM] Port IslAst to the new ScopPassManager

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

show more ...

[Fortran Support] Materialize outermost dimension for Fortran array.

- We use the outermost dimension of arrays since we need this
information to generate GPU transfers.

- In general, if we do not

[Fortran Support] Materialize outermost dimension for Fortran array.

- We use the outermost dimension of arrays since we need this
information to generate GPU transfers.

- In general, if we do not know the outermost dimension of the array
(because the indexing expression is non-affine, for example) then we
simply cannot generate transfer code.

- However, for Fortran arrays, we can use the Fortran array
representation which stores the dimensions of all arrays.

- This patch uses the Fortran array representation to generate code that
computes the outermost dimension size.

Differential Revision: https://reviews.llvm.org/D32967

llvm-svn: 303429

show more ...