Ok, I think I understand things a little bit better now. Thanks for the
explanation! I can see how if the IRBuilder handles all state then there is not
really much of a point to having classes for the parser. It might be worthwhile
to mention having a stateful parser class as an alternative in the Alternatives
section (with the mentioned disadvantages around duplicating logic).
Two more questions:
Given that IRBuilder maintains all state, how does it determine what context to
use for evaluating expressions. Say I have
```python
@T.prim_func
def f(a: T.Buffer[2, "float32"]):
...
```
And I want this buffer to be a `TIRBuffer` when the language is tir and a
`RelaxBuffer` when the language is relax. Is this possible? From my reading,
the parser and IRBuilder are only called for statements and for function calls.
Is this correct? Or can you register a parser for any node in the ast (instead
of just statements)?
Anther question is how does this IRBuilder approach handle error catching and
reporting? Lets say we have
```python
@T.prim_func
def f(a: T.handle):
with T.block(...):
A = T.match_buffer(a, ["a string", 1], "float32")
# ^^^^^^^^^^
# An error should be reported here because the second arguments to
match_buffer should be a `Sequence[Union[int, T.Var]]`
```
If I understand correctly, the `T.match_buffer` call is `eval`uated within a
python context. This context calls `match_buffer` on the IRBuilder. Then the
IRBuilder constructs a `MatchBuffer` object which in turn throws an error
because its second argument has the wrong type. How is this error and error
location then bubbled back up to the user?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/79#issuecomment-1204583687
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/79/[email protected]>
