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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
