Closed #3146.
--
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/3146#event-2364173993
consolidate to #3202
--
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/3146#issuecomment-495443680
I call it feature manager because calling it feature sounds strange. My plan is
to implement feature (an enum), feature set (a datastructure recording the
enum), and functions on them. They will be used in the pass manager.
--
You are receiving this because you are subscribed to this thread.
Re
I think this is something that could be implemented by Sequential. Instead of
rolling a separate manager, let us just rolling in such features incrementally.
For example, the pass could declare it can only take in ANF or graph form, and
the Sequential can be equipped to either resolve automatica
Yes, I agree this is annoying. It looks we might need to introduce some
metadata for a pass. Usually when we do sequential passes, we may need to
consider about preserving information from the updated passes and also validate
if we can proceed. We should think about it more when we start resolvi
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
@slyubomirsky they give stronger gurantee: when the whole pipeline fail, we can
point our finger at one pass that is at fault (some pass take tons of feature
and just pass them further down the pipeline, so it isnt always the case that
the previous pass is at fault).
--
You are receiving this
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
During the development of relay passes, a problem come up repeatedly: a pass
often get input it does not expect, and as a result, it fail (either
implicitly, taking exponential time or produce incorrect output, or explicitly,
typically when a functor does not get match). typical example is
inte
Closed #3223.
--
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/3223#event-2363184420
Thanks for all the discussions, a summary of guidelines:
- For constructor that initializes the fields, use the constructor.
- Encourage static factory function on the reference data type(instead of the
Node) if there are more complicated construction logic and the function naming
gives more cle
11 matches
Mail list logo
