[Comb] Add canonicalization for comb.truth_table

[MrRoy09]

Adds canonicalization patterns and tests for comb.truth_table:

• Folds truth tables with constant output (all true or all false entries) into hw.constant
• Simplifies truth tables that depend on a single input to the corresponding input value
• Adds tests verifying canonicalization behavior for comb.truth_table

Closes #8925

[fzi-hielscher]

Thanks! The implementation and tests look very nice. I'm just not sure whether this really should be a canonicalization pattern. Considering the exponential growth of truth tables this could very easily have a massive effect on runtime . And it doesn't make much sense to apply this pattern repeatedly in the canonicalization convergence loop since it only depends on the truth table itself. I think we should move this to a dedicated pass instead. WDYT @uenoku?

[uenoku]

Cool, thank you for adding this! LGTM!

[uenoku]

And it doesn't make much sense to apply this pattern repeatedly in the canonicalization convergence loop since it only depends on the truth table itself.

I think that's fair concern (though the table size is already 2^n so i don't think it's going to be a critical regression). Maybe we can use the same pattern for canonicalization and dedicated pass and for canonicalization it might makes sense to restrict the lut size to small (e.g. 4 inputs). WDYT? @fzi-hielscher

Alternatively we can also disable the canonicalization for negation and simply find identity patterns
00001111, 00110011 and 01010101 which may be suitable for even folder.

[fzi-hielscher]

Yeah, not touching truth tables beyond a certain limit sounds sensible to me. That being said, I don't have an idea what sizes we are dealing with in practice and what a "reasonable" limit would be.

[teqdruid]

We've been talking about introducing a '-O1' pass for the core dialect as we're definitely abusing canonicalizers for some of them. If there's any debate, this would be a good candidate for having in that pass.

[uenoku]

Based on the discussion above, do you mind if you could create a dedicated pass for TruthTable optimization? I think it's ok to keep allSame optimization in the canonicalization since it's cheap to do.

[fzi-hielscher]

I think it's ok to keep allSame optimization in the canonicalization since it's cheap to do.

That would still be exponential over the number of inputs, wouldn't it? Granted, most likely it will hit an early exit quickly, but worst case we'd still have to look at every single of the 2^n entries.

Realistically there is a fairly narrow window in which truth tables are large enough to be a performance concern but not too large to do anything with them. But if we are within that window I'd prefer not to multiply compilation time by some factor x only to repeatedly determine that the pattern cannot be applied. And having this in a canonicalizer would give us no way to opt-out other than turning off all canonicalizations.

[uenoku]

I don't have a strong opinion on this so I'm fine with not to implement it as canonicalization (note that the truth table attribute already has O(2^n) size, and the verifier already checks all elements on every verifier run so I may disagree with the performance concern here). Regardless whether or not to include this canonicalization pattern, certainly we should use DenseBoolArrayAttr instead of BoolArrayAttr for TruthTableOp. This would improve memory usage and enable efficient bit-level operations, allowing checks like allSame to be computed in O(2^n/64) time rather than O(2^n) (so easily scale to 8 inputs, which should be more than enough for modern FPGA

[MrRoy09]

Based on the discussion above, do you mind if you could create a dedicated pass for TruthTable optimization? I think it's ok to keep allSame optimization in the canonicalization since it's cheap to do.

Based on the discussion, it sounds like the TruthTable optimizations, including the allSame case, should be moved into a dedicated pass. I’m happy to work on that.

I’ll create a new PR for the pass once its ready.