Thanks, @manupa-arm.
Of course, we will! The ultimate goal of TensorIR is to replace the current TE
schedule.
Before integrating it to `relay`, we need to finish all of our M2 items (there
are only two left). Here are the following steps:
- TensorIR docs and tutorial
- Relay integration
- Met
Hi @junrushao1994 @Hzfengsy ,
Thanks for the effort that goes in here. Some of this scheduling primitives are
really useful that are not there in TE.
Will there be a task to integrate these scheduling primitives to be used by
main compilation flow? (i.e. relay.build) ?
--
You are receiving th
Merged #26 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/26#event-5216568281
Thanks @huajsj
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/26#issuecomment-906932927
In reviewing the feedback, it appears that there is a preference for including
easier access for some specialized pages, and ordering the layout in a way that
moves through the user and developer journey of beginner to expert. I've
refined the discussion into a new structure that attempts to a
And I think the just-another-pass approach implies some of the private
machinery in te_compliler needs to be hoisted to be reusable for all
lowering-like passes. Eg LowerTensorExprMutator. So instead of
monolithic lowering + target-specific callbacks
we have
target-specific lowering passes +
> One core distinction here is that the tir_to_runtime hook isn't a pass, it's
> an override of code generation.
Ah, excellent, that's where we've been trying to get to but when we started
this conversation the refactoring to support it seemed to much to foist upon
you. But we've now (thanks Li
