The current approach used by auto_scheduler to extract tuning tasks leverages
Relay op strategy. In short, auto_scheduler registers an implementation in
Relay op strategy as AutoTVM, but instead of using the TOPI schedule function,
auto_scheduler creates an empty schedule and extracts the lowe
Thanks @t-vi . To achieve you are describing we might need to use pyobject as
primary container and source of reference counting. Notably due to the design
constraint of making Object language invariant we cannot do that. The plus side
though is that the object can be access in deployment from
I don't think serialization would necessarily preclude you from having a 1-1
relation between C++ and Python objects -- deserializing would create a new C++
object so I would not expect that you get back the same Python object. Now I
can see how we would not serialize all stuff people attach t
I made this, in the end I stayed in the PyTorch frontend and solved it locally
given that inplace things don't look like TVM that much.
https://github.com/apache/incubator-tvm/pull/6900
---
[Visit
Topic](https://discuss.tvm.apache.org/t/incremental-type-propagation/7446/10)
to respond.
@jroesch and I were talking about this a little. We were thinking of
subclassing Span. You'd have SourceSpan which comes from files and then
ModelSpan (probably could use a better name) for handling layers/nodes in
models. This gets around the issue of having meaningless line fields for spans
Not sure whether it makes sense to revive such an old RFC, but has there been
any progress on a relay AOT? IMHO this would be very much needed, especially
for microcontrollers.
---
[Visit Topic](https://discuss.tvm.apache.org/t/guideline-relay-aot/5977/2) to
respond.
You are receiving th
Thanks @t-vi I agree that keeping the python interface pythonic is one goal we
should strive to achieve. One principle there is to cause less surprises.
In the meantime, we do have the other design constraints, that requires us to
make sure core data structures are self-contained without opaqu
I don't think guarding against specific use cases is more a hack. In the end,
you'll have many funny effects with this type of logic. If you add something to
a set, do you expect the exact object to be in the set afterwards?
In the end, one would need to think about whether having the Python in
However your example code brings up a great point that we should perhaps shoot
a warning when users tries to assign to subclasses of the FFI objects. (perhaps
via overloading setattr or add empty slots to all subclasses)
---
[Visit
Topic](https://discuss.tvm.apache.org/t/round-tripping-ob
I see, if we build a complete function then we can attach the map as an
attribute of the function. But in your case the usage seems to be the
conversion phase. In this case usually map(context) is can be kept as a member
of Mutator(if we make most transformations as member function of that mut
The difficulty with the map is that you need to pass the map around or make it
global state.
My usecase is the PyTorch frontend (which could be made object-oriented instead
of made purely functional to keep track of the map and prelude which is
currently kept track of by indirection). Concrete
In this particular case, because most of the FFI objects are IR nodes, we want
to keep them self-contained. Putting opaque object inside the IR node would
also make things related to the IR harder, such as print the code as textformat.
On the other hand, the need to attach meta-data of specifi
I'm working on this, but I'd still need feedback on whether to implement an own
IR node or try to squeeze into using a call node somehow.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/discuss-running-graphs-when-ops-arent-supported/4482/33)
to respond.
You are receiving this because
Hi,
I've been implementing graph transformations in Python and sometimes it is
handy to add annotations to nodes. Now, running these through an ExprMutator
will give me all new nodes and they're gone. But actually, they're gone ealier
than that:
```python
x = tvm.relay.var('x', shape=(1,1))
x
I would like to add one `flags` attribute to make us have more extension for
the future. Like we could have `Span: (sourcename: ..., line:... column:...
flags: SPFlagSourceNameImportedFromModel, ...)` Then we could query the flags
attribute to handle the specific condition.
---
[Visit
To
15 matches
Mail list logo
