-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[nnc] Updated IR cloning to create clones of expressions in addition to statements #62833
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
Conversation
…to statements [ghstack-poisoned]
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 28dd109 (more details on the Dr. CI page):
🕵️ 1 new failure recognized by patternsThe following CI failures do not appear to be due to upstream breakages:
|
@navahgar has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
class SyncThreads; | ||
class ExternalCall; | ||
|
||
class TORCH_API IRCloner : public IRMutator { |
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.
Should we separate IRCloner from IRMutator? They server for very different purposes and it looks weird that we do clone
in the name of mutate
. Since the IRCloner has its own mutations on expressions and stmts now, I guess there's not much code it can reuse from IRMutator?
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.
Actually, I considered this and I personally didn't have a strong preference either way. And it was just simpler to keep it same as before.
If you have a strong preference to doing this, I can do it in a separate PR.
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.
Overall looks good, I have one question about cloning behavior with Bufs (see below).
case IRNodeType::kRshift: | ||
return new Rshift(lhs_new, rhs_new); | ||
default: | ||
throw unsupported_dtype(); |
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.
Nit: we probably should throw a different error here, it's not related to dtype.
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.
Yeah. Replaced with unimplemented_lowering
.
return new Load(v->dtype(), buf_new, indices_new); | ||
} | ||
|
||
Expr* IRCloner::mutate(Buf* v) { |
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.
That's a bit awkward that we're cloning Buf, but not cloning Vars. I understand why we might have to do this (since Buf might contain expressions in dims that need to be cloned), but it still could be a surprising behavior. Maybe for consistency we then should be cloning Vars too? Or if that's too breaking, we might consider not cloning Bufs (and its inner expressions). Either way, please document the desired behavior somewhere
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 debated about this. But went ahead with cloning buffers for the exact reasons you mentioned (because the expressions in dims and initializers).
Since the difference between cloning Buf and not cloning Var could be confusing as you said, I have reverted to not cloning both of them. The only case I can think of so far which could change the expressions in dims of Buf is buffer compression. And for that case, anyways all the kernel code should be analyzed and it is better to have the clones point to the same Buf.
If something comes up later, we can revisit this assumption and add cloning for Buf and Var.
indices_new.push_back(ind->accept_mutator(this)); | ||
} | ||
auto value_new = v->value()->accept_mutator(this); | ||
return new Store(v->buf(), indices_new, value_new); |
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.
We have a mutator for Buf, but we're not calling it here. Is that intentional? In what situations are we cloning the Buf?
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.
Yeah, I missed that. Thanks for catching that. Fixed now.
…n addition to statements" Differential Revision: [D30135980](https://our.internmc.facebook.com/intern/diff/D30135980) [ghstack-poisoned]
@navahgar has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
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!
…n addition to statements" Differential Revision: [D30135980](https://our.internmc.facebook.com/intern/diff/D30135980) [ghstack-poisoned]
@navahgar has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
…n addition to statements" Differential Revision: [D30135980](https://our.internmc.facebook.com/intern/diff/D30135980) [ghstack-poisoned]
@navahgar has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
…n addition to statements" Differential Revision: [D30135980](https://our.internmc.facebook.com/intern/diff/D30135980) [ghstack-poisoned]
@navahgar has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
Stack from ghstack:
Differential Revision: D30135980