Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

opt hangs on large addition w/ passes_bisect_limit>1280 #4411

Open
Labels
bugSomething isn't working or is incorrect fuzz optimizerRelated to IR optimization or analysis

Description

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

  1. 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
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working or is incorrect fuzz optimizerRelated to IR optimization or analysis

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

        AltStyle によって変換されたページ (->オリジナル) /