Thanks @srush! I totally agree!
Simplifying the scheduling language is definitely an important issue,
especially when we want to approach broader audience.
An idea to make it happen is to compose schedule "primitives" into more
high-level "composite rules". For example, making "tiling + cache
So generally BYOC caters to two types of use cases that are mostly to handle
accelerators and optimized operator libraries (e.g., Arm Compute Library,
DNNL). I think in the world of micro, both of these should be invoked in the
target_host via Driver/Runtime API component. i.e., even though th
Hi @Hzfengsy, Thanks for your answer, that makes a lot of sense.
However, what I am trying to communicate is that even with a new TIR and the
ability to print it out at each step, the underlying scheduling language seems
to be roughly the same in all of these examples (with the nice exception
Thank you for such a valuable question.
Your understanding is correct. We still need a schedule language to schedule.
That is because we need a simple API and abstraction for both human experts and
automatical optimization (like AutoTVM, Ansor, and our new meta-schedule).
Also, we try to kee
Yeah, I think your explanation is a good summary. I see what you mean about the
TensorIR blocks
My understanding though is that the user doesn't actually write TensorIR
(except maybe to start), they still schedule with a separate language? The
blocks in TIR seem really nice, but I still worry
>One of the things missing is a way to say the codegen name in the
>runtime.Module without overloading type_key.
I agree. I don't know exactly the best way to proceed here--we likely need
another RFC. The limitation is that with C++ runtime, the external compiler in
BYOC is expected to produc
Hi @areusch ,
Thanks for taking time to put this all up. Overall it makes sense to me.
>
> (TODO, but not as a result of this RFC) Group the non-host modules by
> target_type (except that ext_dev target_types should be expanded to a unique
> key per BYOC). Save each generated module into a fi
Thanks for the quick reply. This is for logging though, correct? I'm looking
for a way of examining values without adding code & rebuilding - to understand
the flow of the code. That would happen much faster without rebuilding,
rerunning and grepping logs.
---
[Visit Topic](https://discus
In TVM we can define our own ReprPrinter for different subclasses of ObjectRef.
Try `LOG(INFO) << some_object_ref`
---
[Visit Topic](https://discuss.tvm.apache.org/t/debugging-libtvm-so/9134/2) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from
