Closed #1979 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/1979#event-8188077875
You are receiving this because you are subscribed to this thread.
Message ID:
@Mousius to specifically answer your questions on IntImm for bool and int.
Likely this is due to the way we use container and checkers. Right now IntImm
is indeed designed to hold for int and bool. And we will need to specific type
checking on dtype which might be missed in such a case. Differen
@tqchen RFC rejected 😸
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1375932226
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #96.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/96#event-8183713990
You are receiving this because you are subscribed to this thread.
Message ID:
I think we have all made our points pretty clear.
>From technical pov I do not think have clear namespacing or scoping would
>bring inconsistency, and if any, that would be more of a minor issue by
>looking at the embedded API. They would be significant when looking at the
>broader community
> It will however, come with benefit of clarity for broader TVM communty
> members who are interested in Bx but not in B, or both in (Bx-B) and B. As a
> result the requested change, which i believe would be net positive for
> developer users both in (Bx - B) and B. They are pretty actionable wi
We both agree that there are other aspects such as documentation of C that can
be further improved, and also agree that they should not be part of this RFC.
> strong requirement
I was referring to the fact that the cost of maintaining namespacing is not a
strong requirement for this particular
Thanks @leandron @Mousius for helpful suggestions in readability, we have
incorporated most of them. We would like still keep discussions of prior work
design(in this case matx) both in prior Art as well as in the section of
respective context to give clarity and context for the reader (this is
> The suggestions are made on that basis not only considering embedded C and
> rust API(we should of course take that into consideration as part of the
> process like you suggested), but also general TVM project(and broader tvm
> community) as a whole for this specific context of rust language i
