[TIR] Refactor division simplification in RewriteSimplifier

[LeiWang1999]

For example:

x = tir.Var("x", "float32")
ry = x / 27
sy = ana.rewrite_simplify(ry)

In previous versions, the division would be rewritten as x * T.float32(1 / 27), which could lead to unexpected behavior.

This commit removes the special-case rule for rewriting division by a constant float in RewriteSimplifier.
Additionally, it adds a new test to verify the behavior of float-division simplification, ensuring divisions are preserved as-is instead of being rewritten into multiplications.

Related discussion: https://discuss.tvm.apache.org/t/discuss-is-constant-division-to-multiplication-rewrite-in-tvm-necessary/18615

[tqchen]

needs to update the testcase and we are good to go

[LeiWang1999]

looks like this pr already includes a related test. Is there anything that needs to be improved? @tqchen

[tqchen]

Sorry, i meant the failed test case in the CI needs to be updated to reflect the new logic. so ci is green https://ci.tlcpack.ai/blue/organizations/jenkins/tvm-unity/detail/PR-18319/1/ there is structural tests that expects the transformed IR likely the failure is due to expected results in previous transformed logic

[LeiWang1999]

I think we should have a further discussion, because some of the constant‑folding and algebraic rewrites may also introduce similar issues. Examples include:

• (x * c1) * c2 → x * (c1 * c2)
• (x / c1) / c2 → x / (c1 * c2) (with correct division semantics)
• (x * c1) / c2 simplified if c1 divisible by c2, or vice versa.
• (x / c1) + c2 normalized into a single division when possible.
• (y + z) * x → y * x + z * x
• (x + c1) * c2 → x * c2 + c1 * c2
• y*x + z*x → (y+z) * x

However, these rewrites are important for optimization and performance, I think we should consider introducing a deterministic switch or similar option that can disable these transformations when strict, this pr should be closed.

[tqchen]

thanks @LeiWang1999 , one thing we might be able to do is to restrict some of the operations only to integer expressions, which won't have the issue