> Introducing changes to TIR would needs some additional thoughts that deserves
> some extra consideration. Due to the N*M complexity (where N is the TIR
> possibilities and M is the number of primitives to be supported) that needs
> to be handled in implementation (by backend implementers and p
I'm merging this RFC as it seems that our discussion has reached consensus, but
feel free to follow-up any time!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/74#issuecomment-1162072459
You are receiving this because you are subscribed to this thre
Merged #74 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/74#event-6849482980
You are receiving this because you are subscribed to this thread.
Message ID:
Hi @tqchen @kparzysz-quic @kparzysz-quic @masahi @tkonolige @smeijer1234 ,
We are looking to revive this work. I have gone through the thread.
Summary so far is as follows :
* We want to introduce/enhance a scheduling vectorization primitive that could
be controlled by user/auto-tuner/auto-sche
My idea looks at adding official TVM tensor expression implementations of
kernels from the polybench benchmarking system.
It's possible that some kernels do not make sense within the TVM programming
model, however I still believe there is value here.
I've started my implementation, but would l
I am working on optimizing ResNeSt, and I have met the denormal issues. The
following is the solution, which sets denormal numbers to zero.
But I am confused that **where should I put the codes**. There are some
requirements:
1. Target should be checked. This solution can only be applied to
