Fixed a fuzzer timeout issue

[piy-ushk]

Fixes a fuzzer timeout issue where the optimization passes (SelectRangeSimplificationPass and NarrowingPass) hang on very wide bit-width operations (e.g., 1697-bit integers from crasher run_crasher_test_2026-05-05_45c4.x).

Root Cause
When the fuzzer generates wide integer operations (such as multiplications, divisions, and modulos), the RangeQueryEngine and PartialInfoQueryEngine attempt range analysis. Evaluating these complex operations on extremely wide types involves calculating the Cartesian product of the operands' intervals (up to 256 evaluations). This repeatedly executes costly multi-precision integer operations (e.g., bits_ops::UMul, bits_ops::UDiv), causing a huge CPU bottleneck and leading to fuzzer timeouts.

Fix
PartialInfoQueryEngine: Added multiplication, division, and modulo operations (Op::kUMul, Op::kSMul, Op::kUDiv, Op::kSDiv, Op::kUMod, Op::kSMod) to IsExpensiveToEvaluate(). If the operand width exceeds kComplexEvaluationLimit (256 bits), it skips ternary/partial evaluation.
RangeQueryEngine: Added a similar threshold limit (kComplexEvaluationLimit = 256) to the visitor handlers for these operations (HandleUMul, HandleSMul, HandleUDiv, HandleSDiv, HandleUMod, HandleSMod), returning a maximal/unconstrained interval set immediately instead of running expensive interval operations.

Fixes: #4209

[allight]

Thanks for taking the time to contribute!

This explanation for the slowdown seems very unlikely.

Does the test pass with your patch applied? Do you have profiles (pprof or perf) showing the issue is in calculating the bignum multiplication? 1k-bit multiplies aren't free but doing 200 of them should take very little time.

In python randomly choosing then multiplying 1 million pairs of 2000 bit integers takes only 7 seconds on my macbook.

% python3
Python 3.9.6 (default, Mar  6 2026, 16:22:43)
[Clang 21.0.0 (clang-2100.0.123.102)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> import random
>>> timeit.timeit(lambda: random.randint(1<<1000, 1<<2000) * random.randint(1<<1000, 1<<2000), number=1000000)
7.3839869999999905

Also your patch seems to only check on operand 0 for all the nodes but (unlike the shifts that make up the other slow operations) these multiplies are equally affected by the size of both operands.

If I had to guess I'd say the actual issue is far more likely to be with the the BDD query engine falling over on these large multiplies if you still want to look into this.

Also please link to the bug you're fixing in the pull request message with

Bug: https://github.com/google/xls/issues/4209

or Fixes: <github url>.