Allow InferReadWrite to combine shared-address R/W ports when appropriate

[albert-magyar]

I would categorize this as an "RFC" to see if anyone is interested in expanded readwrite inference. In cases where a read and write port of a SyncReadMem share the same clock and address, the semantics of the default undefined read-under-write behavior mean that it is legal to combine the ports into an RW port. The definition of this behavior in the spec implies that this is legal even in cases where there is a partial write mask.

Type of improvement: enhancement of optional inference pass
API impact: none
Backend code-generation impact: when --infer-rw is enabled, more RW inference may occur
Release notes:
The existing, optional InferReadWrite pass may now infer readwrite ports from read/write port pairs that share the same clock and address for undefined read-under-write synchronous-read memories. Previously recognized cases with mutually exclusive read and write enables will continue to be combined as before.

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you update the FIRRTL spec to include every new feature/behavior?
• 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 state the API impact?
• Did you specify the code generation impact?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels?
• Did you mark the proper milestone (1.2.x, 1.3.0, 1.4.0) ?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you mark as Please Merge?

[ekiwi]

This is very cool!

I think we can prevent users from shooting themselves in the foot by changing the default ReadUnderWrite behavior of SyncReadMem in chisel to match the way it is normally emitted: ReadUnderWrite.New.
This way users will have to explicitly enable the undefined behavior if they want to take advantage of the optimization. If that is the case, I would be in favor of enabling your proposed optimization by default.

[albert-magyar]

Superseded by #2111