The test code has a lot of repetition and I am strongly in favor of refactoring
existing tests (some of which show a fair bit of bitrot) to use common
libraries. Testing error cases would also be a good thing to have shared
infrastructure for.
--
You are receiving this because you are subscrib
I am very much in favor of changing the representation of `ConstructorValue`,
as having to keep the module around (to ensure pointer equality) caused me a
bit of pain in my Relay to Python compiler PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email dire
I do like the idea of documenting what a pass can and cannot handle and
ensuring that input (if possible) is appropriately sanitized or errors out
immediately. There are a few analyses we should implement to facilitate writing
passes anyway, like checking for effects, so having checks built into
True
--
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/3236#issuecomment-495427554
Could you give an example of the metaprogramming? E.g., one of creating some
value in ordinary Python and then referencing it from TVMScript
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/79#issuecomment-1198590164
You are receiving this because you
So if you define a variable in a quoted portion, you should be able to
reference it in the quoted portion?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/79#issuecomment-1198624317
You are receiving this because you are subscribed to this thread.
M
On the point about potentially incorporating symbolic shapes into Relay, I
would like to hear more detail about how it can be done with Relay's system of
accumulating type constraints and solving them simultaneously. If we were to
handle dynamic shapes in Relay, we would need to define semantics
For those interested, I think [this recent
paper](https://arxiv.org/pdf/2210.02374.pdf) shows one way as to how symbolic
shapes could be make to work with Relay's type checking approach (Axon is
clearly structured very similarly to Relay), though it would require
substantially reworking the exi
I wonder about a situation where some parties indicate up front that they are
resolutely opposed to ever permitting an S0 module to become S1. Even if this
process permits the module to be merged as S0, it would essentially be known in
advance that it is unlikely ever to be fully integrated into
Closed #14287 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/14287#event-8745998119
You are receiving this because you are subscribed to this thread.
Message ID:
Conclusion from Relax open development meeting: We think this error is correct
and that we should not permit `DataflowVar`s in `StructInfo` annotations. Using
an explicit `R.output` will eliminate the error in this case. We will consider
whether further syntactic sugar or automated help is neces
[Rendered
view.](https://github.com/slyubomirsky/tvm-rfcs/blob/tir-spec/rfcs/0101-tir-spec.md)
This RFC proposes including a language specification ([draft
included](https://github.com/slyubomirsky/tvm-rfcs/blob/tir-spec/rfcs/assets/0101/spec.md))
for TIR in TVM's documentation.
Many thanks to
Requesting reviews from some in the community who are knowledgeable about TIR:
@Hzfengsy @tqchen @junrushao @Lunderberg @vinx13 @cyx-6 @MasterJH5574
I would also welcome suggestions on other TIR contributors whose attention
should be drawn to this RFC.
Perhaps it might make sense to set up a ch
@kparzysz-quic @yzh119 Perhaps you might also be interested in reviewing (feel
free to tag others as well).
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/101#issuecomment-1638604597
You are receiving this because you are subscribed to this thread.
I've added an update for recently added inter-`PrimFunc` calls, please have a
look!
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/101#issuecomment-1863631509
You are receiving this because you are subscribed to this thread.
Message ID:
It's worth noting that with the merging of Unity into TVM's main branch, Relax
has already been _de facto_ upstreamed.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/89#issuecomment-1904942456
You are receiving this because you are subscribed to thi
[Rendered
view.](https://github.com/slyubomirsky/tvm-rfcs/blob/relax-spec/rfcs/0106-relax-spec.md)
Now that Unity has been merged into TVM's main branch, I have written an
RFC to make my [unofficial Relax
specification](https://github.com/apache/tvm/pull/14148) an official one, akin
to the [TI
There doesn't seem to be any particular reason I can think of for the Relay
module not to import the prelude by default, with a flag present for when it
should not be imported (e.g., if you want to reclaim the names for some
reason). It shouldn't lead to any overhead at run time since a dead c
I don't know how helpful this will be since it's old, but I had an ancient
abandoned PR that tried to add in mutual recursion. I ran into some unification
bugs that I documented in the comments, but maybe those have since been fixed.
Seems like it has to do with type variables (the woes of dep
To be clear, it seems like I was able to get my cludge of a solution to "work"
but it required annotating more types than I thought it should. It might be
that this is the best we can do, but the lack of graceful errors (again, at the
time -- I know @jroesch has done a lot of work to improve R
Maybe just encouraging (or even requiring) types to be annotated when mutual
recursion is at play will sidestep a lot of issues with checking those.
---
[Visit
Topic](https://discuss.tvm.ai/t/wip-relay-mutual-recursion-development/7118/4)
to respond.
You are receiving this because you en
# RFC: Type-Directed Relay Fuzzing Library
## Summary
This RFC proposes to employ fuzzing (mass generation of random programs) for
Relay in order to test the compiler. Fuzz testing for Relay can expose bugs and
improve confidence in the compiler by generating vastly more test cases than
can
Nightly or less-frequent runs make sense for docs, since nothing will be "on
fire" if a tutorial breaks (though they should still be fixed).
---
[Visit
Topic](https://discuss.tvm.apache.org/t/discuss-tvm-unity-transition-docs-refactor/16325/12)
to respond.
You are receiving this because
23 matches
Mail list logo
