Re: [apache/tvm-rfcs] [RFC][TIR] Separate physical and logical layout of buffers (#39)

How will vectorization work? If there is a `vectorize` directive spanning a logical extent, will the vectorization pass create multidimensional `ramp`s? How will vector loads and stores be represented? -- You are receiving this because you are subscribed to this thread. Reply to this email di

Re: [apache/tvm-rfcs] [RFC][TIR] Separate physical and logical layout of buffers (#39)

True, and that would allow both for user-defined mappings, and for specifying standard layouts. I have a bit of concern with using the `scope` parameter to also describe layouts, since in my mind "scope" refers to where the entire buffer is located, while "layout" refers to how individual eleme

Re: [apache/tvm-rfcs] [RFC][Project API] Extend metadata in ProjectOption (#33)

> @gromero please take a look at the comments here and lmk when it's ready for > another review @areusch Hi. Please take a look. I've also added the text stressing that every option must be associated at least to one API method, as per our discussion last week in the Meetup. Thanks. -- You ar

Re: [apache/tvm-rfcs] [RFC] Update script block syntax (#41)

The syntax of block bindings looks good to me! Specially it makes it really clear to the readers that there is a "block binding" to avoid future surprise. BTW, do we have a reference for the behavior of auto-completion on T.read/write? -- You are receiving this because you are subscribed to thi

Re: [apache/tvm-rfcs] [RFC] Update script block syntax (#41)

Rendered text: https://github.com/apache/tvm-rfcs/blob/67df92fea29d4e667adfe149d7b2b1420c344b47/rfcs/0041-script-block-syntax.md -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/41#issu

Re: [apache/tvm-rfcs] [RFC][TIR] Separate physical and logical layout of buffers (#39)

One way to represent the layout mapping in TIR is to introduce different storage scopes and have a registry of pre-defined layout mapping (for example, we already did similar thing for [`wmma` fragments](https://github.com/apache/tvm/blob/813136401a11a49d6c15e6013c34dd822a5c4ff6/python/tvm/topi/

Re: [apache/tvm-rfcs] [RFC][TIR] Separate physical and logical layout of buffers (#39)

Thank you for the comments, @vinx13. > For example, another way is to use a mapping function: (n, c, h, w) -> (n, > tir.floordiv(c, 4), h, w, tir.floormod(c, 4)). This would allow arbitrary > mapping (we can add more restrictions like requiring affine mapping though, > to make analysis easier).

[apache/tvm-rfcs] [RFC] Update script block syntax (#41)

It's the rfc for a new block syntax in TVMScript. Co-authored-by: Junru Shao Co-authored-by: Zihao Ye Co-authored-by: Tianqi Chen You can view, comment on, or merge this pull request online at: https://github.co

[apache/tvm-rfcs] [RFC][TIR] 1-d AllocateNode::extent (#40)

This RFC changes `Array AllocateNode::extents` to `PrimExpr AllocateNode::extent`, giving the 1-d size of the buffer to be allocated. This is part of the separation between logical layout and physical layout, proposed in [RFC#0039](https://github.com/apache/tvm-rfcs/pull/0039). TODO: