gemini-code-assist[bot] commented on code in PR #18400:
URL: https://github.com/apache/tvm/pull/18400#discussion_r2464143764
##########
tests/python/relax/test_frontend_from_exported_program.py:
##########
@@ -371,25 +401,67 @@ def forward(self, input):
return torch.ops.aten.hardswish_(input)
@tvm.script.ir_module
- class expected1:
+ class expected_hardswish_for_1_2:
@R.function
def main(
inp_0: R.Tensor((1, 3, 10, 10), dtype="float32")
) -> R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")):
with R.dataflow():
- lv: R.Tensor((1, 3, 10, 10), dtype="float32") = R.add(inp_0,
R.const(3, "float32"))
- lv1: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(lv, 0,
6)
- lv2: R.Tensor((1, 3, 10, 10), dtype="float32") = R.divide(
- lv1, R.const(6, "float32")
+ lv: R.Tensor((1, 3, 10, 10), dtype="float32") = R.add(
+ inp_0, R.const(3.0, "float32")
+ )
+ lv1: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(
+ lv, R.prim_value(0), R.prim_value(T.float64("inf"))
+ )
+ lv2: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(
+ lv1, R.prim_value(T.float64("-inf")), R.prim_value(6)
)
lv3: R.Tensor((1, 3, 10, 10), dtype="float32") =
R.multiply(inp_0, lv2)
- gv: R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")) = (lv3,)
+ lv4: R.Tensor((1, 3, 10, 10), dtype="float32") = R.divide(
+ lv3, R.const(6.0, "float32")
+ )
+ gv: R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")) = (lv4,)
R.output(gv)
return gv
- verify_model(Hardswish(), example_args, {}, expected1)
- verify_model(Hardswish2(), example_args, {}, expected1)
- verify_model(Hardswish3(), example_args, {}, expected1)
+ @tvm.script.ir_module
+ class expected_hardswish_for_3:
+ @R.function
+ def main(
+ input: R.Tensor((1, 3, 10, 10), dtype="float32")
+ ) -> R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"), R.Tensor((1, 3, 10,
10), dtype="float32")
+ ):
+ with R.dataflow():
+ lv: R.Tensor((1, 3, 10, 10), dtype="float32") = R.add(
+ input, R.const(3.0, "float32")
+ )
+ lv1: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(
+ lv, R.prim_value(0), R.prim_value(T.float64("inf"))
+ )
+ lv2: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(
+ lv1, R.prim_value(T.float64("-inf")), R.prim_value(6)
+ )
+ lv3: R.Tensor((1, 3, 10, 10), dtype="float32") =
R.multiply(input, lv2)
+ lv4: R.Tensor((1, 3, 10, 10), dtype="float32") = R.divide(
+ lv3, R.const(6.0, "float32")
+ )
+ gv: R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ ) = (lv4, lv4)
+ R.output(gv)
+ return gv
Review Comment:
The expected IR for the inplace `hardswish_` operation returns a tuple of
two identical tensors. This is inconsistent with the original PyTorch model
`Hardswish3`, which returns a single tensor. This pattern also appears in the
test for `relu6_` (`expected_relu6_3`). While this might be an intended
consequence of how inplace operations are handled after decomposition, it's
confusing. The translated function should ideally match the return signature of
the original model. Could you clarify if this is intended, or adjust the
expected IR to return a single tensor?
##########
tests/python/relax/test_frontend_from_exported_program.py:
##########
@@ -558,9 +630,28 @@ def main(
R.output(gv)
return gv
- verify_model(ReLU6_1(), example_args, {}, expected_relu6_1)
- verify_model(ReLU6_2(), example_args, {}, expected_relu6_2)
- verify_model(ReLU6_3(), example_args, {}, expected_relu6_2)
+ @tvm.script.ir_module
+ class expected_relu6_3:
+ @R.function
+ def main(
+ x: R.Tensor((1, 3, 10, 10), dtype="float32")
+ ) -> R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"), R.Tensor((1, 3, 10,
10), dtype="float32")
+ ):
+ with R.dataflow():
+ lv: R.Tensor((1, 3, 10, 10), dtype="float32") = R.clip(
+ x, R.prim_value(0), R.prim_value(6)
+ )
+ gv: R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ ) = (lv, lv)
+ R.output(gv)
+ return gv
+
+ verify_model(ReLU6_1(), example_args, {}, expected_relu6_1,
run_ep_decomposition=True)
+ verify_model(ReLU6_2(), example_args, {}, expected_relu6_2,
run_ep_decomposition=True)
Review Comment:
There seems to be an inconsistency in how `relu6` is handled. The test for
`ReLU6_1` (using `nn.ReLU6`) shows that it's decomposed into `relax.op.clip`,
which is expected with `run_ep_decomposition=True`. However, this test for
`ReLU6_2` (using `F.relu6`) is expected to be translated to
`relax.op.nn.relu6`, indicating it's not decomposed. Since both tests use
`run_ep_decomposition=True`, this difference is surprising. Is this discrepancy
in PyTorch's decomposition behavior expected?
##########
tests/python/relax/test_frontend_from_exported_program.py:
##########
@@ -266,20 +265,44 @@ def forward(self, input):
return torch.ops.aten.dropout_(input, 0.5, train=True)
@tvm.script.ir_module
- class expected_dropout:
+ class expected_dropout_for_1_2:
@R.function
def main(
- input_1: R.Tensor((1, 3, 10, 10), dtype="float32")
+ input: R.Tensor((1, 3, 10, 10), dtype="float32")
) -> R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")):
# block 0
with R.dataflow():
- gv: R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")) =
(input_1,)
+ gv: R.Tuple(R.Tensor((1, 3, 10, 10), dtype="float32")) =
(input,)
R.output(gv)
return gv
- verify_model(Dropout1(), example_args, {}, expected_dropout)
- verify_model(Dropout2(), example_args, {}, expected_dropout)
- verify_model(Dropout3(), example_args, {}, expected_dropout)
+ @tvm.script.ir_module
+ class expected_dropout_for_3:
+ @R.function
+ def main(
+ input: R.Tensor((1, 3, 10, 10), dtype="float32")
+ ) -> R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"), R.Tensor((1, 3, 10,
10), dtype="float32")
+ ):
+ # block 0
+ with R.dataflow():
+ lv: R.Tensor((1, 3, 10, 10), dtype="float32") = R.zeros(
+ R.shape([1, 3, 10, 10]), dtype="float32"
+ )
+ lv1: R.Tensor((1, 3, 10, 10), dtype="float32") = R.divide(
+ lv, R.const(0.5, "float32")
+ )
+ lv2: R.Tensor((1, 3, 10, 10), dtype="float32") =
R.multiply(input, lv1)
+ gv: R.Tuple(
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ R.Tensor((1, 3, 10, 10), dtype="float32"),
+ ) = (lv2, lv2)
+ R.output(gv)
+ return gv
Review Comment:
The expected IR for `Dropout3` seems incorrect as it will always produce a
zero tensor. The logic `R.zeros(...)` followed by `R.divide` and `R.multiply`
results in a zero tensor, which does not correctly model the behavior of
dropout, even for deterministic testing. This seems to be caused by the
translation of `torch.empty_like` to `relax.op.zeros_like`, which then leads to
a zero mask after the `bernoulli` operation. This testing logic for dropout
should be revisited to correctly reflect its behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
