Hi Roman,
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 25 2016
Dec 23 2016
Dec 21 2016
Update according to the comments.
Update according to the comments.
Why is the _access_ relation mapping to a 9 dimensional space. You talk about a _schedule_ here, right?
Dec 19 2016
Could you add some more information to the commit message:
Hi Michael,
Dec 17 2016
For example, getAddressFunction() can return the following map . Subsequently, Memory::applyScheduleToAccessRelation tries to apply the schedule to its domain.
Dec 15 2016
Hi Roman,
Oct 18 2016
In D25653#572527, @grosser wrote:Hi Roman,
the general direction looks fine to me. Two questions:
Hi Michael,
Oct 16 2016
Sep 13 2016
Hi Tobias,
A new version updated according to the comments.
Sep 12 2016
I think that the first dimensions is always nullptr, and all others are never nullptr. This is what your code is written for, but we can be more general, where nullptr could be at any position.
Hi Michael,
A new version updated according to the comments.
Aug 31 2016
Hi Michael,
A new version updated according to the comments.
Aug 30 2016
Hi Michael,
A new version updated according to the comments.
Aug 29 2016
Aug 27 2016
Fix misprints.
In D23260#521852, @grosser wrote:Hi Roman,
thanks for this update:
Aug 26 2016
Hi Michael,
Aug 21 2016
This is a new version of the patch updated according to the comments.
Aug 20 2016
Hi Tobias,
Aug 16 2016
Hi Michael,
Aug 15 2016
Hi Tobias,
Aug 13 2016
A new version of the patch updated according to the comments.
Aug 11 2016
Hi Tobias,
Aug 9 2016
Hi Michael,
Aug 8 2016
In this version the issue related to wrong access function of B type matrices is fixed and redundant functions are removed.
In this draft of the patch copy statements are represented as Scop statements whose values of BB and R fields are equal to nullptr. These statements have only two memory accesses. The first one represents reading from an array that should be packed. The second one represents writing to a created array. What do you think about it?
Aug 1 2016
As far as I understand, it is more intuitive to remap all accesses to the array to a new array using, for example, the following function:
A new version of the patch updated according to the comments.
Jul 30 2016
I get the following error:
"error: ‘polly::PollyIRBuilder’ has no member named ‘GetCurrentBlock’"
If I'm not mistaken, IRBuilder doesn't have methods that return basic
blocks.
Jul 29 2016
I would make this a plain pointer and use a unique_ptr to track ownership in ScopArrayInfoSet
Jul 28 2016
Hi Tobias,
Jul 27 2016
Thanks for the comments! I've tried to address them in this version of the patch.
Jul 26 2016
This is a draft of the path. I think that it has at least the following drawbacks:
Jul 25 2016
@grosser, @Meinersbur, @mreisinger, thank you for the comments! I've tried to address them in r276616 and r276627.
Jul 20 2016
Jul 18 2016
Also, AFAIU only one of the two matrices A and B needs to be transposed. Consequently, I would expect that only one of them has to be mapped. You seem to want to map two arrays - MemRef_6 and MemRef_7. Why is this necessary?
Jul 17 2016
In D22187#486278, @grosser wrote:In D22187#486221, @gareevroman wrote:In D22187#486206, @grosser wrote:Hi Roman,
I may not yet fully unserstand this issue, but don't you transform all accesses to the matrix. Assume you don't transpose a submatrix but the full matrix A would applying the mapping A[x0][x1] -> A2[x1][x0] on all accesses what you want to do. The same should hold when you are working with submatrixes, except that the mapping function is slightly more complicated.
Yes, I think this is true.
I guess I figured out. Thanks.
It is not possible that, for example, A[i][j] and A[i][k] of the following access relations S1[i, j, k]->A[i][j] and S2[i, j, k]->A[i, k], which may correspond to the following code, have the same identifier. Consequently, we'll be able to remap only one of these two accesses, if we apply A[i][j] -> New[x][y][z], using the interface. Is it right?
Not sure what you mean by the same identifier. It still seems you want to apply the mapping only to a subset of the memory references by somehow identifying the ones on which you want to apply the mapping through the identifiers in their access function. Is this true?
@vivekvpandya, no worries. I just tried to understand the issue.
OK. I'll commit it. @vivekvpandya, @mreisinger do you have a commit access? Sorry, I don't know whether you have it. Usually authors commit their patches.
Jul 16 2016
In D22187#486206, @grosser wrote:Hi Roman,
I may not yet fully unserstand this issue, but don't you transform all accesses to the matrix. Assume you don't transpose a submatrix but the full matrix A would applying the mapping A[x0][x1] -> A2[x1][x0] on all accesses what you want to do. The same should hold when you are working with submatrixes, except that the mapping function is slightly more complicated.
Jul 15 2016
Hi Michael,
- I am not sure I like the interface to replace memory accesses. It seems this interface takes a specific memory access relation and replaces all accesses that have this specific relation the new access relation. I understand that this might work, but wonder if another interface might not be more intuitive. One could e.g. provide a relation
A[i][j] -> New[x][y][z] which is applied to all accesses to remap all accesses to A to a new array. Would such an interface work for your transformation?
Jul 14 2016
- I am not sure I like the interface to replace memory accesses. It seems this interface takes a specific memory access relation and replaces all accesses that have this specific relation the new access relation. I understand that this might work, but wonder if another interface might not be more intuitive. One could e.g. provide a relation
A[i][j] -> New[x][y][z] which is applied to all accesses to remap all accesses to A to a new array. Would such an interface work for your transformation?
Yes, I think that an ability to remap specific memory accesses to A is unnecessary for the transformation and such an interfaces would work fine for it.
In D22187#480166, @grosser wrote:Hi Roman,
thanks for your work. Even though this is still WIP, here already some first commtents:
Jul 13 2016
The test case was missed.
Hi Tobias,
Jul 11 2016
Fix wrong comments and names of variables.
Jul 9 2016
Fix incomplete comments.
This is a draft of the third patch to apply the BLIS matmul optimization pattern on matmul kernels. It should probably be split to separate modification of the existent code (creation of macro kernel, determination its parameters http://reviews.llvm.org/D21491) and replacement of access relations.
Jul 5 2016
In D21283#474829, @grosser wrote:Has this patch been committed?
Jun 24 2016
Changed according to the comments.
Jun 21 2016
In D21491#462093, @Meinersbur wrote:Thanks for the patch and meaningful comments.
Jun 18 2016
This is a draft of the second patch to apply the BLIS matmul optimization pattern on matmul kernels. I'm not sure how it is better to implement interchanging of loops using schedule trees. That's why I would be very grateful for your comments, feedback and ideas.
Jun 13 2016
Hi Tobias,
Jun 12 2016
Hi Tobias,
Jun 8 2016
I haven't yet found out how to get throughput of vector instructions per clock cycle and latency of instructions That's why these values are passed as command line parameters. Maybe TargetTransformInfo::getArithmeticInstrCost can be used for this purpose. However, I haven't found an algorithm that is used by target architectures to compute a cost in TargetTransformInfoImpl.
Jun 3 2016
Thank you for the comment!
May 31 2016
May 28 2016
-instnamer was used.
Thank you for the explanation! This version of a patch adds positive and negative test cases. I’ve also fixed issues related to the isInputDimUsed and the debug output of the optimizeBand.
May 27 2016
Hello Tobias,
May 24 2016
This is a first draft, which contains determination of the following class of statements: