BTW, after writing it down, we can find that perhaps it is not necessary (for
S1) to explicitly introduce a special vscale. Another approach is that we can
mark an SVE scope, and use a normal tvm variable `n` to mark the sve extent.
```python
# note vscale = n
n = T.let(call(tvm.builtin.vscale(), ()))
for y in range(64):
for x in range(64 // n):
with T.sve_scope(n) as tid:
a0: vector<vscale> = A[y, tid + n * x]
b0: scalar = B[y]
b1: vector<vscale> = b0 + 1
c0: scalar = a0 * b0
C[y, tid + n * 4 * i] = c0
```
This circles back to our questions about how to deal with `vscale`. My feeling
is that having a special intrin marking it(and use call) would be useful once
per function(or SVE scope). Then we can reuse normal arithmetic analysis built
for integer variables, without worrying too much about a special vscale.
Generalizing things a bit, say we are looking into higher dimensional
instructions(e.g. SME), likely we need two or more variables (instead of a
single vscale). Introducing a new variable node for each can become less
tractable, but the reality is that we just need to be able to know that they
are variables, and be able to track them through context, so having a var with
annotation somewhere likely can serve similar purposes.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/104#issuecomment-1699183708
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/104/c1699183...@github.com>
