@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 follow-up 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#issuecomment-494547366
