Root Cause Analysis for Fuzzer Crasher / Timeout (crasher_2026-06-04_5aa4)
Failure Overview
the fuzzer sample crasher_2026-06-04_5aa4.x encountered a tool timeout during IR optimization:
Subprocess call timed out after 1500 seconds: /xls/tools/opt_main sample.ir --logtostderr
Reproduction & Minimization
- Converted the DSLX code to IR using
ir_converter_main:
ir_converter_main -- \
--top=main --lower_to_proc_scoped_channels=false \
--package_name=sample --warnings_as_errors=false \
third_party/xls/fuzzer/crashers/crasher_2026-06-04_5aa4.x > sample.ir
- Executed
opt_main using compiler fuel (--passes_bisect_limit=N):
- At
--passes_bisect_limit=1000: optimization completed 1000 passes in ~0.4s.
- At
--passes_bisect_limit=1124: optimization ran normally up to pass 1124 (completing default_pipeline).
- At pass 1280 (inside
simp / strength_red pass): execution runtime blew up significantly (~4 seconds per pass iteration).
Root Cause
The DSLX sample operates on a massive narrow integer width (bits[1593]).
During late fixed-point simplifications (strength_reduction_pass.cc), the pass continuously identifies narrow addition operations where carries cannot propagate:
strength_reduction_pass.cc:626] Add cannot propagate carries to bit 8; replacing with two adders: add.533: bits[1492] = add(...)
...
strength_reduction_pass.cc:626] Add cannot propagate carries to bit 6; replacing with two adders: add.565: bits[1482] = add(...)
Because the pass splits a single bits[1593] addition into two adders, chipping away 2 to 12 bits on each iteration, it runs hundreds of successive fixed-point simplification iterations. Each fixed-point iteration re-evaluates the entire node set (~110 passes), leading to severe quadratic/cubic runtime blowup (~10+ minutes overall), exceeding the fuzzer's 1500-second execution budget.
Next Steps
- Optimize
strength_reduction_pass to perform bulk carry-split evaluations or bound the number of iterative multi-adder sub-splits generated for exceptionally large bit widths.
Root Cause Analysis for Fuzzer Crasher / Timeout (
crasher_2026-06-04_5aa4)Failure Overview
the fuzzer sample
crasher_2026-06-04_5aa4.xencountered a tool timeout during IR optimization:Reproduction & Minimization
ir_converter_main:ir_converter_main -- \ --top=main --lower_to_proc_scoped_channels=false \ --package_name=sample --warnings_as_errors=false \ third_party/xls/fuzzer/crashers/crasher_2026-06-04_5aa4.x > sample.iropt_mainusing compiler fuel (--passes_bisect_limit=N):--passes_bisect_limit=1000: optimization completed 1000 passes in ~0.4s.--passes_bisect_limit=1124: optimization ran normally up to pass 1124 (completingdefault_pipeline).simp/strength_redpass): execution runtime blew up significantly (~4 seconds per pass iteration).Root Cause
The DSLX sample operates on a massive narrow integer width (
bits[1593]).During late fixed-point simplifications (
strength_reduction_pass.cc), the pass continuously identifies narrow addition operations where carries cannot propagate:Because the pass splits a single
bits[1593]addition into two adders, chipping away 2 to 12 bits on each iteration, it runs hundreds of successive fixed-point simplification iterations. Each fixed-point iteration re-evaluates the entire node set (~110 passes), leading to severe quadratic/cubic runtime blowup (~10+ minutes overall), exceeding the fuzzer's 1500-second execution budget.Next Steps
strength_reduction_passto perform bulk carry-split evaluations or bound the number of iterative multi-adder sub-splits generated for exceptionally large bit widths.