Repository navigation
[Relax][PyTorch] Cast non-bool inputs to bool in logical_and converter - #19679
Merged
Merged
Conversation
torch.logical_and returns a boolean tensor for any input dtype, but relax.op.logical_and requires boolean inputs. The exported-program frontend lowered logical_and directly to relax.op.logical_and, which fails LegalizeOps for non-bool inputs, and the FX frontend did not support logical_and at all. Add a shared converter that casts non-bool operands to bool first, matching torch and the existing logical_not converter, and register it for both frontends.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request implements a custom translator for torch.logical_and in the TVM Relax PyTorch frontend. The new _logical_and method casts non-boolean inputs to boolean first, aligning with PyTorch's behavior. This translator is registered in both FX and Exported Program translators, and corresponding tests are added. A review comment suggests adding safety checks to ensure struct_info is an instance of relax.TensorStructInfo before accessing its dtype to prevent potential AttributeErrors.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
cchung100m
approved these changes
Jun 8, 2026
cchung100m
left a comment
cchung100m
left a comment
Contributor
There was a problem hiding this comment.
LGTM, thanks to @javierdejesusda
tlopex
pushed a commit
that referenced
this pull request
Jun 13, 2026
### Motivation `torch.logical_or` and `torch.logical_xor` accept input tensors of any dtype (treating any nonzero element as `True`) and always return a `bool` tensor. Neither op was handled by the PyTorch frontend. The ExportedProgram frontend did not register `logical_or.default` / `logical_xor.default`, and the FX frontend did not register `logical_or` / `logical_xor`, so importing a model that uses either op failed early with `Unsupported function types`. This follows up on #19679 (`logical_and`) and addresses the explicit question raised in #19743: whether `logical_or` and `logical_xor` need the same handling. ### Changes - Add shared `_logical_or` and `_logical_xor` converters in `BaseFXGraphImporter` that cast non-bool operands to `bool` before applying `relax.op.logical_or` / `relax.op.logical_xor`. Bool operands are passed through unchanged (no redundant cast). - Register `logical_or.default` / `logical_xor.default` (ExportedProgram) and `logical_or` / `logical_xor` (FX), matching the existing `logical_and` converter. - Add standalone `test_logical_or` and `test_logical_xor` to both the FX and ExportedProgram test suites, asserting the corrected IR (`astype` to bool on each operand, then the logical op, producing a `bool` output). ### Notes The cast to `bool` lowers to an elementwise nonzero test, so it matches PyTorch's "nonzero is True" semantics for float, integer, and NaN inputs.
MasterJH5574
pushed a commit
to MasterJH5574/tvm
that referenced
this pull request
Jun 15, 2026
apache#19679) ### Motivation `torch.logical_and` accepts input tensors of any dtype (treating any nonzero element as `True`) and always returns a `bool` tensor. The PyTorch frontend did not produce that `bool` result. The ExportedProgram frontend lowered `logical_and.default` with `self._binary_op(relax.op.logical_and, operator.and_)`, which kept the operand dtype and emitted `relax.op.logical_and` on non-bool inputs (for example `float32`). `relax.op.logical_and` requires boolean inputs and otherwise fails `LegalizeOps` in the TOPI `logical_and`. The FX frontend did not register `logical_and` at all, so the op was unsupported there. ### Changes - Add a shared `_logical_and` converter in `BaseFXGraphImporter` that casts non-bool operands to `bool` before applying `relax.op.logical_and`. Bool operands are passed through unchanged (no redundant cast). - Point the `logical_and.default` (ExportedProgram) registration at the new converter, and add a `logical_and` (FX) registration that was previously missing, matching the existing `logical_not` converter. - Add a standalone `test_logical_and` to both the FX and ExportedProgram test suites asserting the corrected IR (`astype` to bool on each operand, then `logical_and`, producing a `bool` output). ### Notes The cast to `bool` lowers to an elementwise nonzero test, so it matches PyTorch's "nonzero is True" semantics for float, integer, and NaN inputs. (cherry picked from commit 0e32507)
MasterJH5574
pushed a commit
to MasterJH5574/tvm
that referenced
this pull request
Jun 15, 2026
apache#19679) ### Motivation `torch.logical_and` accepts input tensors of any dtype (treating any nonzero element as `True`) and always returns a `bool` tensor. The PyTorch frontend did not produce that `bool` result. The ExportedProgram frontend lowered `logical_and.default` with `self._binary_op(relax.op.logical_and, operator.and_)`, which kept the operand dtype and emitted `relax.op.logical_and` on non-bool inputs (for example `float32`). `relax.op.logical_and` requires boolean inputs and otherwise fails `LegalizeOps` in the TOPI `logical_and`. The FX frontend did not register `logical_and` at all, so the op was unsupported there. ### Changes - Add a shared `_logical_and` converter in `BaseFXGraphImporter` that casts non-bool operands to `bool` before applying `relax.op.logical_and`. Bool operands are passed through unchanged (no redundant cast). - Point the `logical_and.default` (ExportedProgram) registration at the new converter, and add a `logical_and` (FX) registration that was previously missing, matching the existing `logical_not` converter. - Add a standalone `test_logical_and` to both the FX and ExportedProgram test suites asserting the corrected IR (`astype` to bool on each operand, then `logical_and`, producing a `bool` output). ### Notes The cast to `bool` lowers to an elementwise nonzero test, so it matches PyTorch's "nonzero is True" semantics for float, integer, and NaN inputs. (cherry picked from commit 0e32507)
MasterJH5574
pushed a commit
to MasterJH5574/tvm
that referenced
this pull request
Jun 15, 2026
) ### Motivation `torch.logical_or` and `torch.logical_xor` accept input tensors of any dtype (treating any nonzero element as `True`) and always return a `bool` tensor. Neither op was handled by the PyTorch frontend. The ExportedProgram frontend did not register `logical_or.default` / `logical_xor.default`, and the FX frontend did not register `logical_or` / `logical_xor`, so importing a model that uses either op failed early with `Unsupported function types`. This follows up on apache#19679 (`logical_and`) and addresses the explicit question raised in apache#19743: whether `logical_or` and `logical_xor` need the same handling. ### Changes - Add shared `_logical_or` and `_logical_xor` converters in `BaseFXGraphImporter` that cast non-bool operands to `bool` before applying `relax.op.logical_or` / `relax.op.logical_xor`. Bool operands are passed through unchanged (no redundant cast). - Register `logical_or.default` / `logical_xor.default` (ExportedProgram) and `logical_or` / `logical_xor` (FX), matching the existing `logical_and` converter. - Add standalone `test_logical_or` and `test_logical_xor` to both the FX and ExportedProgram test suites, asserting the corrected IR (`astype` to bool on each operand, then the logical op, producing a `bool` output). ### Notes The cast to `bool` lowers to an elementwise nonzero test, so it matches PyTorch's "nonzero is True" semantics for float, integer, and NaN inputs. (cherry picked from commit f5e8a3a)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
torch.logical_andaccepts input tensors of any dtype (treating any nonzeroelement as
True) and always returns abooltensor.The PyTorch frontend did not produce that
boolresult. The ExportedProgramfrontend lowered
logical_and.defaultwithself._binary_op(relax.op.logical_and, operator.and_), which kept the operanddtype and emitted
relax.op.logical_andon non-bool inputs (for examplefloat32).relax.op.logical_andrequires boolean inputs and otherwise failsLegalizeOpsin the TOPIlogical_and. The FX frontend did not registerlogical_andat all, so the op was unsupported there.Changes
_logical_andconverter inBaseFXGraphImporterthat castsnon-bool operands to
boolbefore applyingrelax.op.logical_and. Booloperands are passed through unchanged (no redundant cast).
logical_and.default(ExportedProgram) registration at the newconverter, and add a
logical_and(FX) registration that was previouslymissing, matching the existing
logical_notconverter.test_logical_andto both the FX and ExportedProgram testsuites asserting the corrected IR (
astypeto bool on each operand, thenlogical_and, producing abooloutput).Notes
The cast to
boollowers to an elementwise nonzero test, so it matchesPyTorch's "nonzero is True" semantics for float, integer, and NaN inputs.