* LLVM bump (as we know it)
* minor format fix
* DCMAKE_BUILD_TYPE=?
* Update lib/Dialect/MSFT/MSFTOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* Update lib/Dialect/FIRRTL/FIRRTLOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* Update lib/Dialect/Calyx/CalyxOps.cpp
Co-authored-by: Andrew Young <youngar17@gmail.com>
* removed anon module test
Co-authored-by: Andrew Young <youngar17@gmail.com>
This commit defines a ChainingProblem, which models the accumulation of physical propagation delays on combinational paths along SSA dependences within a scheduling problem's abstract time steps/cycles.
s/SharedPipelinedOperatorsProblem/SharedOperatorsProblem
The "pipelined" in the name is kind of redundant because fully-pipelined operators currently are the default assumption in the modeling.
- Add parameter S to the simplex tableau.
- Keep track of variable locations in the tableau.
- Add entry point in Algorithms.h.
- Set up test pass, prepare test cases.
Extends the basic problem model with a new operator type property 'limit', representing the maximum number of operations that can "use" a given operator type in each time step.
This scheduler uses linear programming and a handwritten simplex solver to compute the II and start times for the CyclicProblem. It's an implementation of the approach proposed in:
B. D. de Dinechin, "Simplex Scheduling: More than Lifetime-Sensitive Instruction Scheduling", PRISM 1994.22, 1994.
Straightforward extension of the basic scheduling problem:
- Dependences have an optional distance property.
- The cyclic problem has a solution property initiation interval (II).
- The solution is valid iff for each dependence i -> j with distance dist
(default value 0, if not set), i finishes before j starts dist
iterations/samples/pipeline starts/etc. later.
Formally: startTime(i) + latency(assocOpr(i)) <= startTime(j) + dist * II
This allows testing the `check()`/`verify()` facilities in the Problem class by reading a given schedule from the test case. Tests like this are useful because they let us test new problem models in case a suitable algorithm is still being implemented, or can only live out-of-tree.
I also separated normal and error tests, as per convention.