[DC] Add merge lowering #6943
[DC] Add merge lowering #6943
Conversation
Modelled after the Handshake lowering, however, becomes trivial with a 2-input merge.
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>
|
|
||
| if (!data.empty()) { | ||
| // Data-merge; mux the selected input. | ||
| auto dataMux = rewriter.create<arith::SelectOp>( |
There was a problem hiding this comment.
Does something lower arith.select to an hw.mux?
There was a problem hiding this comment.
map-arith-to-comb will lower this to a comb.mux.
| // Pack the data mux with the control token. | ||
| mergeOutput = pack(rewriter, selectedIndexUnpacked.token, dataMux); | ||
| } else { | ||
| // Control-only merge; throw away the index value of the dc.merge |
There was a problem hiding this comment.
- Unlike
dc.merge,handshake.mergedoesn't output the idx of the value which got selected. This is why you had alarm bells going off. - When would a
handshake.mergehave no data? Since handshake is all about dynamic data flow, I don't think it ever would. In the context of a lowering, evennonewould be considered data, yes? - If
noneis implicitly converted todc.token, then this makes sense.
There was a problem hiding this comment.
If none is implicitly converted to dc.token, then this makes sense.
it is - see
When would a handshake.merge have no data? Since handshake is all about dynamic data flow, I don't think it ever would. In the context of a lowering, even none would be considered data, yes?
True, in practice, i've never seen this used. The DHLS lowerings used data merge ops but these could always be boiled down to single-input merges (i.e. a no-op). So your observation is correct, and there is a good argument for removing handshake.merge from the dialect.
Modelled after the Handshake lowering, however, becomes trivial with a 2-input merge.