Lunderberg commented on a change in pull request #9727:
URL: https://github.com/apache/tvm/pull/9727#discussion_r769882395
##########
File path: include/tvm/tir/buffer.h
##########
@@ -127,7 +174,7 @@ class BufferNode : public Object {
* without adjusting for number of lanes. (e.g. The number of
* float16x4 elements in a buffer of type float16x4.)
*/
- PrimExpr ElemOffset(Array<PrimExpr> index) const;
+ Array<PrimExpr> ElemOffset(Array<PrimExpr> index) const;
Review comment:
Good point, though I think there would need to be some additional
terminology introduced. The options I had thought about were below.
* Keep the same function names. Not as informative as it could be, because
it doesn't indicate whether the input/output indices correspond to specific
indices elsewhere in the flow (e.g. those specified by the user or expressed to
low-level code generation).
* Rename to `Array<PrimExpr> GetPhysicalIndex(Array<PrimExpr>
logical_index)`. Not quite true, since the indices passed in should be after
any layout transformations have been applied, but before flattening.
`logical_index` would imply that it takes indices exactly as specified in the
`te.compute` definition.
* Rename to `Array<PrimExpr> GetPhysicalIndex(Array<PrimExpr>
transformed_index)`. Not quite true, since it implies that passing in
post-transformation indices can always output the physical index. The Buffer
object must be modified by the transformation first, before the transformed
index can be passed in.
* Rename to `Array<PrimExpr> FlattenIndex(Array<PrimExpr> index)`.
Actually, now that I look at that, I kind of like that one. It doesn't imply
additional functionality, and
After writing out the different options, I think it makes sense to rename it
to `FlattenIndex`, along with adding a comment that this should be used after
all transformations have been applied, and produces the physical index.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
