tkonolige commented on PR #79:
URL: https://github.com/apache/tvm-rfcs/pull/79#issuecomment-1204583687
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?
--
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]
