[Draft] [OpLib] Create a Dialect for Representing Operator Libraries #7771
+899
−11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening a draft PR to start getting comments while I finish up the verifier implementation and testing.
The goal of this PR is to introduce a new OpLib library that represents a library of operators in CIRCT. The initial intended use for this library is to unify the representation of operators for SCFToCalyx and LoopScheduleToCalyx. Instead of each pass having their own mapping from high-level operations to a calyx primitive, there will first be a pass that inserts the operator library and then both passes will look at the operator library to determine lowerings. We can also use this information in AffineToLoopSchedule to build the scheduling problem without hardcoding latency and delay information.
After this initial use, OpLib could be augmented to support lowerings to dialects other than Calyx as well as allowing users to add their own custom operators. Supporting variable bitwidth operators that have functions from bitwidth to delay is also something I am interested in implementing eventually.
Example:
Singling in on the
@fmult
operator, we see it has a latency of 4 an incoming delay of 0.5 ns and an outgoing delay of 0.5 ns. Theoplib.target
defines a match target. In this example we will match againstarith.mulf
operations. Theoplib.calyx_match
defines what calyx primitive to produce if the target is matched. In this case we produce a custom calyx primitive for an external floating point multiplier.oplib.calyx_match
verifies that the target type bitwidths match the yielded ins and outs type bitwidths.Let me know if there are any questions or comments about how this works. I will also implement the use of operators in SCFToCalyx before finalizing this PR (but won't yet remove the hardcoded operators).