[Fix][Relax][Frontend][Torch] Follow torch's dtype rules for the division family

[hiyufan]

Stacked on #20372 — the first commit here is that PR; this PR is the second commit. It reuses the scalar-promotion helpers from #20372, so it should land after it (or I can rebase onto main once that merges).

Problem

Three converters disagree with torch on what a division returns.

expression	tensor dtype	torch	frontend on main
x / 2	int64 [3, 4, 5]	float32 [1.5, 2.0, 2.5]	int64 [1, 2, 2]
x / (x + 1)	int64	float32 [0.75, 0.8, 0.83]	int64 [0, 0, 0]
x / 2	bool	float32 [0.5, 0.5, 0.0]	bool
2 / x	int64 [3, 4, 5]	float32 [0.67, 0.5, 0.4]	int64 [0, 0, 0]
torch.reciprocal(x)	int64	float32	int64
x // 2	int64 / float32	int64 / float32	TypeError (same-dtype check)
torch.div(x, 2, rounding_mode="trunc")	int64	int64 [-3, -1, 1, 3]	TypeError
torch.div(x, 2, rounding_mode="floor")	int64	int64 [-4, -2, 1, 3]	TypeError

Three causes:

1. div.Tensor / div.Scalar went through the generic _binary_op, which keeps the promoted dtype. torch's true division always yields a floating result — int64 / 2 and int64 / int64 are float32 — which is a rule on top of torch.result_type (an int scalar alone does not widen an int tensor), so it needs its own converter.
2. div.Tensor_mode — what x // 2 and torch.div(x, s, rounding_mode=…) decompose to under run_decompositions() — built its constant with relax.const(inp_2) and no dtype, i.e. int32. Every float tensor and every non-int32 integer tensor then failed relax's same-dtype check. The int32 case passed only because relax.const's default dtype happens to be int32.
3. reciprocal.default, what scalar / x decomposes to, divided const(1, x.dtype) by x, so 2 / int_tensor was an integer quotient too. The converter was duplicated in fx_translator.py and exported_program_translator.py; there is now one in the base class.

Fix

The two promotion closures inside _binary_op become methods (_promote_binary_operands, _promote_scalar_operand) so the division converters can share them. _true_division_operands applies torch's one extra rule for /:

lhs, rhs = self._promote_binary_operands(lhs, rhs)
if dtype is integral or bool:
    lhs, rhs = astype(lhs, "float32"), astype(rhs, "float32")

• div.Tensor / div.Scalar (and fx truediv) → new _true_divide.
• _div (rounding modes) promotes the same way and then keeps the promoted dtype: floor → floor_divide; trunc on an integer pair → plain divide, since integer division in relax truncates toward zero (checked: [-7, -3, 3, 7] / 2 → [-3, -1, 1, 3]); floats keep divide + trunc.
• _reciprocal → _true_division_operands(1, x) then divide, in the base class.

Verification

The same 864-program sweep as #20372 (18 binary ops × 8 tensor dtypes × 6 Python scalars, built with relax.build(llvm), result dtype and values compared with torch), measured against #20372's head as the base:

	matched	wrong dtype or values	raised
#20372	645	52	132
this PR	799	0	30

Per-case diff of the failure lists: no case fails with this change that did not fail before it; 154 repaired. Every remaining wrong case is gone. The 30 that still raise are the same pre-existing edges noted in #20372 — relax rejecting arithmetic on a bool tensor with a bool scalar, a uint8 tensor against a negative scalar (torch wraps modulo 256, relax.const(-3, "uint8") raises), and x ** True on an integer tensor — plus the four division ops on that same uint8 / -3 input.

test_frontend_from_exported_program.py and test_frontend_from_fx.py: failure sets identical before and after apart from the new tests (8 and 15 pre-existing in my environment). ruff check / ruff format --check clean on all four touched files.

Tests

• test_true_division_of_integers_gives_float — IR-level: int64 / 2 casts both operands to float32 before the divide.
• test_true_division_values — x / s, s / x, x / (x + 1) and torch.reciprocal(x) over int64, int32, uint8 and bool tensors (and a float scalar), asserting dtype and values.
• test_division_with_rounding_mode — x // 2, torch.div(…, "floor"), torch.div(…, "trunc") and a tensor divisor on [-7, -3, 3, 7] for int64, int32 and float32; the negative inputs are what separate floor from trunc.

8 of the 9 fail against #20372's head:

test_true_division_values[int64-2]          result dtype int64, torch gives torch.float32
test_division_with_rounding_mode[int64]     TypeError: ... R.floor_divide(x, R.const(2, "int32")) ... T.int64 on the LHS
test_division_with_rounding_mode[float32]   TypeError: ... T.float32 on the LHS ... T.int32 on the RHS

The ninth, test_division_with_rounding_mode[int32], passes there for the int32-default reason above; it stays in to pin that the path keeps working.

---

This change was prepared with AI assistance (Claude). I have reviewed and verified it, and can speak to it in review.