[GitHub] [tvm-rfcs] vinx13 commented on pull request #70: [RFC] Introducing DeclBuffer

[GitBox <gi...@apache.org>]

vinx13 commented on PR #70:
URL: https://github.com/apache/tvm-rfcs/pull/70#issuecomment-1124141811

   @wrongtest Thanks for bringing up this. There are a few options for the behavior in TVM script, I'm open to discussion.
   
   * A1: The original behavior before https://github.com/apache/tvm/pull/9727:
   `T.allocate` returns a `Var`, which can be later used in `T.load / T.store`.
   
   * A2: Current behavior: 
   `T.allocate` returns a buffer (`Var` is implicitly created inside). The buffer can be accessed via subscripts, which will be translated to `BufferLoad / BufferStore`.
   
   * A3: Potential behavior for this RFC:
   `T.allocate` returns a `Var`, use `T.decl_buffer` to create buffer and access it (because `T.load / T.store` are deprecated). This follows the translation to TIR nodes closely.
   
   * A4: Potential behavior for this RFC (the one @wrongtest is proposing):
   If there are no buffer aliases (in most of the cases), it is tempting to avoid boilerplate code of `T.decl_buffer`. 
   `T.allocate` returns a buffer, where `buffer->data` is implicitly created and allocated inside. The buffer can be accessed via subscripts. Subsequent buffer aliases can be created by referring to `buffer->data`. This requires `DeclBuffer` to be created implicitly, it is okay to have some discrepancy between parser side and the TIR nodes.


-- 
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: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org