[Experimental][Buffers] A simple pass for inserting a single buffer at a specific channel

[Jiahui17]

This pass facilitates externally prototyping a custom buffer placement analysis, e.g., in Python. This also makes the results of some research artifacts (e.g., Mapbuf) developed in Python easily reproducible in the current Dynamatic framework.

A typical workflow would be:

1. Export the handshake_transformed.mlir to DOT, apply some external analysis using Python to determine where to place buffers.
2. Using this pass: add all the buffers, and generate handshake_buffered.mlir.
3. Continue with the rest of the HLS flow.

For example, we can add a buffer by specifying the following (this is for the benchmark fir):

dynamatic-opt handshake_transformed.mlir \
	--handshake-placebuffers-custom="pred=mux1 outid=0 slots=1 type=oehb" \
	--handshake-placebuffers-custom="pred=mux1 outid=0 slots=1 type=tehb" \
	--handshake-placebuffers-custom="pred=mux2 outid=0 slots=1 type=oehb" \
	--handshake-placebuffers-custom="pred=mux2 outid=0 slots=1 type=tehb" \
	--handshake-placebuffers-custom="pred=control_merge2 outid=0 slots=1 type=oehb" \
	--handshake-placebuffers-custom="pred=control_merge2 outid=0 slots=1 type=tehb" \
	> "handshake_buffered.mlir"

dynamatic-opt handshake_buffered.mlir --handshake-canonicalize \
  > handshake_export.mlir

Any suggestions?

[lucas-rami]

Thanks a lot for the contibution :) I think that could be very useful to other Dynamatic developers! I left a couple of minor comments.

For example, we can add a buffer by specifying the following

The convention I have followed so far when having to refer to a specific value use (i.e., channel) externally is by a combination of the consumer's name and operand index (instead of by a combination of producer's name and result index). Different uses of the same SSA value will always have a different consumer or operand index hence the former has the advantage of working even when the IR is not materialized. Since you check that the IR is materialized as a pass pre-condition and that I don't think it makes sense to deal with buffers on unmaterialized IR anyway I am fine leaving this as is, just mentioning it for future work.

At some point I think it would make sense to provide a generic way to insert semi-arbitrary operations in the IR at semi-arbitrary points (by expressing their connections with surrounding operations) to support the kind of workflow you describe in more situations.

[Jiahui17]

Thanks for the comments! I have updated PR accordingly:)

[lucas-rami]

Awesome, thanks for the contribution :)