Optimize BitPat factory from UInt literals

[jackkoenig]

Benchmarked using #3987,

For BitPat(0xdeadbeefL.U) 72x speedup:

Benchmark                           Mode  Cnt   Score   Error   Units
ChiselBenchmark.BitPatFromUInt     thrpt   10  42.105 ± 1.364  ops/us
ChiselBenchmark.BitPatFromUIntOld  thrpt   10   0.582 ± 0.005  ops/us

For BitPat(3.U) 7x speedup:

Benchmark                           Mode  Cnt   Score   Error   Units
ChiselBenchmark.BitPatFromUInt     thrpt    3  44.501 ± 7.054  ops/us
ChiselBenchmark.BitPatFromUIntOld  thrpt   10   5.819 ± 0.049  ops/us

For real design, reduced amount of time in BitPat.apply from 116 seconds to 12.5 seconds (9x speedup)

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• Performance improvement

Desired Merge Strategy

• Squash

Release Notes

Speeds up conversion of UInt literals to BitPat by ~9x in practice, ~70x for large UInts.

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.6.x, 5.x, or 6.x depending on impact, API modification or big change: 7.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[sequencer]

Every time I saw this, I wanna refactor this...
IIRC, Similar dirty codes also exist in the parsing BitPat from String...

[jackkoenig]

IIRC, Similar dirty codes also exist in the parsing BitPat from String...

BitPat.parse is okay (could be slightly optimized) but there are lots of places in TruthTable that could be sped up, I have another PR coming, just trying to figure out the best way to test and benchmark it as it's a private method.

[jackkoenig]

TruthTable.fromString could definitely be optimized a bit 🙂

[sequencer]

TruthTable.fromString could definitely be optimized a bit 🙂

Sorry for my ancient dirty hack 🫣