@ajtulloch @icemelon9 and I have been quietly hacking on a prototype the last few months but
have been busy with other things (such as VM ðŸ˜„ ). We are going to start pushing now, I
opened a draft PR which will contain type checking changes, and we will followup with code
generation next.
One thing would to help validate, criticize the design from the standpoint of a user who is
deploying models day to day, and comment on the code generation strategies.
One change that we have decided on is adding the ability to type hint when generating IR.
When generating IR from frameworks we don't necessarily have all type information up front.
That is you may know a static shape for a value, but the shape is not necessarily a stable
static property.
For example imagine a loop variable which starts as a (1, 1) matrix, but will grow by one
in the first dimension on every loop. Eventually the matrix will have the shape (n, 1) where
`n` is the number of loop iterations but we can't know that statically.
Our current solution is to generate IR with unknown types, plus a type hint, allowing inference
to eventually solve the most general type.
For example if we were to generate IR for a loop we can do:
```
def my_loop(%x: ?T, %y: ?U) {
...
can_unify(%x, shape=(1, 1))
my_loop(concat([%x, %x], axis=0))
...
}
```
These could later be used to inform code generation, but ensure that we get the correct typing.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/3042#issuecomment494547366
