I'm starting work in https://github.com/dmlc/HalideIR/pull/56
--
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/2983#issuecomment-482346276
`NodeRef` is just a type-erased version of `NodePtr` right?
I think the main question is if we want to allow nodes to be implemented in
languages besides C++. If we require nodes to be implemented as `Node`
subclasses, then they have to have C++ impls for inheritance to work. If we
design a `No
I could set it up so that most of the node generation logic + code is in
HalideIR, and then there's a generator script each set of nodes needed (one
here, one there.) I might open a PR over there and start work.
--
You are receiving this because you are subscribed to this thread.
Reply to this
How does the refcounting for Nodes currently work across the ABI boundary? Is
everything owned by the TVM runtime or something?
--
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/2983#issuecom
Oh hm, that's an interesting idea. How would we handle inheritance / methods on
nodes? Just copy-pasting stuff in the generator, or some sort of runtime lookup
system implemented in C?
Another route to ABI compatibility is to just use opaque pointers + accessors
everywhere, that might be a less
> The main question is the naming convention to make sure we are not confusing
> the users.
Yeah I didn't put any thought into these, would welcome suggestions. Could do
something like `set_body_to_function_pointer` / `set_body_to_method_pointer`,
although those are a bit verbose.
--
You are
@tqchen, yeah those are good points. One possibility would be to use
hand-written languages for first-tier-supported languages like python and offer
the auto-generated wrappers for other languages.
If you did end up switching fully to auto-generated wrappers you could take
steps like committing
>From other thread:
@tqchen:
> I will summarize some of my take here. I like the idea of Node hierarchy
> compile time generation. This is something I have thought about and discussed
> with @jroesch for a while and might help [#2523
> (comment)](https://github.com/dmlc/tvm/issues/2523#issuecom
(Moved from #2981)
Proposal: add type signature metadata to PackedFunc
Each `PackedFunc` would have an optional field describing what arguments it
takes and what type it returns. This field would be automatically populated
during conversion from a `TypedPackedFunc`.
Once we have these type si
cc @nhynes @tqchen
--
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/pull/2981#issuecomment-480622604
This PR converts a good chunk of TVM's global `PackedFunc`s to be
`TypedPackedFunc`s. Right now, this shouldn't actually change any behavior,
since the type information is immediately discarded once the functions are
registered in the `Registry`.
It does make things a lot shorter, using a few
Shouldn't title be "Slice on LHS"?
Also @tqchen what's a good way to add that annotation?
--
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/2975#issuecomment-480444869
12 matches
Mail list logo
