DontCare optimization?

[sequencer]

I'm reading bluespec user guide, and found something interesting:

In late stages of the compiler, don’t-care values are converted into specific constants. In order that the Verilog and Bluesim simulation paths produce exactly the same value dumps, the compiler assigns a value to the don’t-care signals at the point where the Verilog and Bluesim back ends diverge. However, the Verilog back end can generate more efficient hardware if it is allowed to assign the don’t-care signals better values based on context. The -opt-undetermined-vals flag permits the Verilog back end of the compiler to make better decisions about don’t-care values. This flag is off by default. Turning this flag on may produce better hardware in Verilog, but can result in the Bluesim and Verilog simulations producing different intermediate values.

I think we can also use SMTLIB to give some optimizations like this. IIRC, currently we treat all DontCare to 0. But the semantic of DontCare is don't care, if we force it to 0, we are certainly miss some optimization opportunity.

Checklist

• [x] Did you write out a description of the feature you want to see?
• [x] Did you look around for any related features?
• [x] Did you specify relevant external information?

Feature Description

Use SMTLIB to optimize FIRRTL generated hardware.

Type of Feature

• performance improvement

External Information

BlueSpec userguide 3.11 Compiler optimizations

[aswaterman]

Agreed in principle, but since this change is virtually guaranteed to expose bugs in existing designs, it should be an optional pass.

[sequencer]

I think so. This will lead to uncertain result to a FIRRTL circuit.

[ekiwi]

This needs a proof of concept that shows a QoR improvement for a particular test case. Then we can think about whether it is worth to implement this optimization.