- Depends on D32967.
- Have rudimentary test cases that this works.
- Would like a thorough review in case I'm missing something obvious in the implementation.
- Putting this up as a [WIP], want to cleanup some of the code.
Details
Diff Detail
- Build Status
Buildable 6890 Build 6890: arc lint + arc unit
Event Timeline
I expected a change in ScopBuilder::buildMemoryAccess as well. Which case there handles Fortran arrays?
- Fix style in PPCGCodeGeneration.cpp
- Docyment methods & fix style in ScopInfo.h
- Simplify`PPCGCodeGeneration.cpp - pollyBuildAstExprForStmt`
This title "Generate GPU kernels for Fortran arrays" is far far too general. You only modify how the "extent" is computed. Please explain in more detail what you are doing.
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | Please explain why this is necessary. | |
2158–2165 | I'd first try to derive the extent from the accesses and only if that fails, and only if that doesn't work, derive the maximal possible extend from the outermost array dimension. That should also work if it is not Fortran array, but whenever all dimension sizes are defined. | |
2183 | Please no const of local variables. I know you like this, but if applied consistently nearly every local variable must be const, adding a lot of syntactic clutter. | |
2449–2450 | Is the coding style in this file supposed to be different than in the rest of Polly? (LLVM coding style says parameter names start with capital letter) | |
test/GPGPU/fortran-copy-kernel-affine.ll | ||
2 | You removed [WIP]. but TODO is still there. | |
14 | Fortran |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | getAddressFunction() calls getAddressRelation() and then lexmins it. This will not work in case of a Fortran array because it's unbounded in the outermost dimension. So, we do the bounding manually. | |
2158–2165 | Hm, so you wish to derive extents from the accesses for Fortran arrays as well? I'm not sure what you're saying, could you please clarify? |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | Wouldn't it a better approach to apply the domain constraints to the access relation in general? We could do this in getAccessFunction() itself, the intersection is done in both acceses. Second, I am not sure this does what you intent to do. For non-affine access indices, this will just give you an expression to the first element of the array, but I think you will want to access other elements as well. What you may want is a case distinction:
| |
2158–2165 | Let's say you have an access for (int i = 5; i < 10; i++) A[i] For this access you need the elements A[5..9] to be transferred, but not A[0..4]. The older preexisting code would get you the range A[5..9]. Your Fortran code would get you the range A[0..N], which includes some unnecessary elements. If you can compute the extent the former way, there is no reason to use the more pessimistic approach to transfer the whole array. You could even compute the extent which might be unbounded in some dimensions, and then interstect with the array dimensions if those are known. |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | found isAffine. However, in IslNodeBuilder.cpp, the following code exists: assert(MA->isAffine() && "Only affine memory accesses can be code generated"); so, I'm not sure how you wish to extract a pw_aff from the original expression, because in a non-affine case it would just be a relation to everything in the output, correct? sample-relation.isl [p_0_loaded_from_n, MemRef0_fortranarr_size, MemRef1_fortranarr_size] -> { Stmt_9[i0] -> MemRef0[o0] } |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | The assertion should only apply if setNewAccessRelation() is used. Otherwise it just tries to reproduce the old pointer, not generating it from the access relation. Btw:
Yes, and we only need the maximum extent of all accesses. In you example, Say the domain is { Stmt_9[i] : 0 <= i < 10 } The extend without bound information would be: { MemRef0[i] : 0 <= i < N } |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | N would be your MemRef0_fortranarr_size. |
lib/CodeGen/PPCGCodeGeneration.cpp | ||
---|---|---|
133–136 | Perhaps I am mis-understanding what the function does.
I don't understand, how does this relate to the creation of the AddrFunc? |
- Check if Fortran array's outermost dimension can be bounded before using the pwAff.
- remove code related to non-linear accesses in pollyBuildAstExprForStmt.
@Meinersbur: I've changed the way getExtent works to only use the outermost dimension parameter in case the size is not bounded statically. I've also changed the getAddressFunction stuff to only-linear.
Could you take another look at the code now? Thanks.
Please explain why this is necessary.