[JIT] Fix a bug of rejecting ops with AliasAnalysisKind::CONSERVATIVE (#64336)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64336
Currently AliasDB rejects any user-defined ops with `AliasAnalysisKind::CONSERVATIVE` if they do not have a special treatment for alias analysis. For example, the following alias schema gets rejects:
```
m.def(torch::schema(
"namescope::my_op(...) -> ...",
c10::AliasAnalysisKind::CONSERVATIVE));
```
This rejection condition is contradictory: AliasDB can handle ops with `CONSERVATIVE` in a general way without any special casing at https://fburl.com/diffusion/op5u72sk calling https://fburl.com/diffusion/h3aws5dd which seems very appropriate to be conservative for alias analysis.
This change corrects the rejection condition to be satisfied for ops *with* special casing but have `CONSERVATIVE`, since they both cannot be used simultaneously.
Test Plan:
Confirmed that
```
m.def(torch::schema(
"namescope::my_op(...) -> ...",
c10::AliasAnalysisKind::CONSERVATIVE));
```
gets accepted and `my_op`'s all inputs and outputs are put to point to wildcard(*) by AliasDB.
Reviewed By: eellison
Differential Revision: D30690121
fbshipit-source-id: 431cc1a84edd5227f52b44a0fd85d5eb16f3c288
diff --git a/torch/csrc/jit/runtime/operator.cpp b/torch/csrc/jit/runtime/operator.cpp
index 6508016..c1265a6 100644
--- a/torch/csrc/jit/runtime/operator.cpp
+++ b/torch/csrc/jit/runtime/operator.cpp
@@ -353,10 +353,10 @@
op.schema().name(),
". File a bug to add a case for this operator.\n");
}
- if (!aliasAnalysisHasSpecialCaseFor(s) &&
+ if (aliasAnalysisHasSpecialCaseFor(s) &&
op.aliasAnalysisKind() == AliasAnalysisKind::CONSERVATIVE) {
AT_ERROR(
- "Missing special case in alias analysis for non-schematized"
+ "Conflict in special casing in alias analysis for non-schematized"
" operator ",
op.schema().name(),
". File a bug to add a case for this operator.\n");
