You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2022/12/07 04:07:18 UTC

[GitHub] [tvm] lightzhan-intellif commented on issue #13559: Remove the position restriction of alloc_buffer

lightzhan-intellif commented on issue #13559:
URL: https://github.com/apache/tvm/issues/13559#issuecomment-1340345620

   Thanks for your reply @junrushao. I think there is no problem as for the case under the new parser:
   ```
   a = 1
   B = T.alloc_buffer(shape=[a, a + 1])
   ```
   Because it is not a let-binding any more for the new parser. Even we do not do any change to the code, it works well for the above code in which  'a' will be replaced by its value '1' in the later stmt.
   
   But there is a problem exactly for real let_binding stmt. It's a little complicated:
   ```
   @T.prim_func
   def test_alloc(in_data: T.Buffer[(256, 256), "float32"]):
       for i, j in T.grid(256, 256):
           with T.block("a"):
               a = i + j
               p = T.alloc_buffer((a, 256), dtype="float32")
               p[i, j] = in_data[i, j]
   ```
   In this case, alloc_buffer can not be moved prior to the definition of 'a', but I think it's not unsolvable. When we reach alloc_buffer, we can check if there is any let-binding variable in the params. If so, we can expand it.
   
   For the more complicated scenarios, we may find the expr we get by expanding the let-binding stmt contains let-binding too. In this case, we can expand the let-binding variable recursively until we can not find any in the final expr.
   
   I notice that you mentioned a solution which enhances the error message. Yes, I think it is a way to go. But there is an another problem. You can imagine how long the code will be if the value of 'a' is so long and we exactly want to use it in the alloc_buffer. What's more, if we want to use the value of 'a' in a sequence of alloc_buffer, there will be a lot of repetitive code in our code text.
   
   So, I think it is also a sytax sugar if we remove the restriction.


-- 
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