-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Relay] add fatal #3911
[Relay] add fatal #3911
Conversation
Mostly looks good and it is good to have a more explicit solution to the problem of incomplete matches. A couple of issues besides the questions I've labeled:
|
Thanks for addressing the feedback. I think these changes are good (pending linting fixes) |
@slyubomirsky can you approve explicitly? |
TVM_REGISTER_API("relay._make.Fatal") | ||
.set_body_typed(FatalNode::make); | ||
|
||
std::string NoMatchMsg() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel we can just use constexpr or an enum to define some common error messages in both C++ and python. Not necessary to define such an API.
otherwise lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to copy the string twice if it is a constant though. I feel like api is cleaner and not cumbersome to use too.
Hi ppl, I add pytest.ini and updated tests/lint/check_file_type.py, is it ok? |
Should there be an AST header on the pytest.ini? The linter is complaining about it, but should the .ini file be an exception? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm.
include/tvm/relay/expr.h
Outdated
@@ -513,6 +513,32 @@ class RefWriteNode : public ExprNode { | |||
|
|||
RELAY_DEFINE_NODE_REF(RefWrite, RefWriteNode, Expr); | |||
|
|||
/*! \brief A fatal error has occured. Stop all execution and report with a message. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/*! \brief A fatal error has occured. Stop all execution and report with a message. */ | |
/*! \brief A fatal error has occurred. Stop all execution and report with a message. */ |
x = Var("x", l(a)) | ||
y = Var("y") | ||
z = Var("z") | ||
nil_case = Clause(PatternConstructor(nil, []), Fatal("cannot pass nil into head")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this line is not used.
044d46b
to
b54b798
Compare
@wweic @icemelon9 I had addressed the review comment, can you guys give another round of review or approve? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. could you fix the CI error?
096a3ba
to
116bdf7
Compare
I was actually just now looking at support for Asserts, so this will be useful to me (Thanks to Wei for pointing me to this PR). I had been wondering what the TVM Relay policy is on side effects? I see that there is already Ref, but I didn't find the policy on it for Relay, and I wonder what it is. Side effects do change how a lot of optimizations can be done. (Turns out, if you Google for "TVM side effects", the result is an official message "FDA Warns Public of TVM Side Effects", so I guess there's that, too.) |
@broune Thanks for bringing it up! cc @tqchen @jroesch @zhiics @icemelon9 Regarding this PR, @MarisaKirisame please rebase so I can approve. |
@broune relay is a purposefully side-effect language - it has side effect, and it is the key ingridient for our automatic differentiation algorithm. |
I think it would be good to introduce a thread discussing side effect. My feeling is that we want to keep most of the code functional(which makes them easy to optimize) and only introduce side effect when necessary(e.g. update rules). Side effect was not necessary for first-order AD, and for higher order ADs, we will need to find out a way to reduce as many as possible, and has not yet becomes concern. In a gist, a large component of optimizations could be focusing on optimizing side-effect free programs. @broune seems to have a lot of thoughts for relaxing the side effect semantics. I think that makes sense especially for asserts, mainly because we only want to receive errors in boundaries of functions(which could be an entire graph) and I think we could reorder things in these cases. |
@broune maybe we can have a longer form discussion and draft an RFC together? the current policy is if you don't use ref, the program should be side-effect free. I believe this may be violated by a few ops but my goal is to avoid side effects, and make it easy to do side-effect free analysis for many use cases. |
I'm happy to discuss further in whichever venue. (No side effects is ideal for optimization but hard to get 100%. E.g. with dynamic shapes, most ops can have shape errors at runtime, making them side effecting unless somehow the error becomes an output in the dataflow graph. A random number generator library like TVM's tvm.contrib.random has random numbers that are different each time you call the op, which is stateful and a side effect.) |
@tqchen that's the point of the PE pass. on another note, can somebody get this merged? this had been sitting for a long time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. @jroesch @icemelon9 please take another look as well.
close for now due to inactive status, feel free to bring another PR to the master |
@jroesch @junrushao1994 @tqchen @wweic @vinx13 @slyubomirsky can you guys review?