Incremental compiling?

[sequencer]

These days I have been thinking how to apply incremental compiling to Chisel.
For example, a big SoC with 8 cores, if we only make a small change, we still need a whole elaborating and FIRRTL transform. That's painful, and consume too much time in FIRRTL transform.
If regard chisel as a build system, it is impossible to define a input from user(we can even use random to change generated circuit each time), so we can never cache the elaboration result. However, after CHIRRL is generated, it is possible to cache the result, since all ir and annotation is cacheable(this implicitly constraint FIRRTL transform is reproducible). So it is possible and reasonable to speed up FIRRTL transform with cache.
However, for current SFC, I think the granularity of Transform need to be more clear: is this transform a Module transform or Circuit transform, in fact, most of transform are module transforms, only global optimization, such as cross module constant prop, boring wires, etc are circuit transform. It means, like software compiler stack, we can also split hardware compiler to compile and link.
At the first pass of FIRRTL, we can split CHIRRTL into different modules with their local annotation, compile them into low-firrtl in parallel, cache final result with CHIRRTL and local annotations as key, finally link generated modules together for cross module optimization(constant propagation). We can also store modules globally, like what ccache did.
This might help for super large designs like 8 core SoCs, just an idea, not start to prototype yet ;p

[jackkoenig]

There has been some discussion about how to make the current FIRRTL compiler incrementalizable, and I've spent a lot of time thinking about it.

You're right that most transforms operate only on individual modules and are thus trivial to parallelize and make incremental--no problem on these and it would be pretty easy to make them work.

It gets harder for transformations that operate globally--Check Combinational Loops, Constant Propagation, and Dead Code Elimination--to name 3. It's still possible, but you then need some system of storing information about the previous incremental result so that the cross-module results can be propagated. Then, if a change you make changes the result on some cross-module boundary, you need a way to "invalidate" other modules to cause a recompilation when necessary.

Even that is doable, but it gets worse. The biggest problem is custom transformations that operate on multiple modules at once. Consider the Wiring Transform. It takes Annotations as inputs and has the effect of transforming the Modules that have the annotated components as well as any Modules in between them. I believe it's possible to make an API that can handle this--each transform implements a function that takes the AnnotationSeq and returns information about what Modules it needs to recompile.

I think there is a way to do this, but the point I'm getting at is that it requires a fundamental redesign of the Transform API and careful consideration of the possible use cases. The good news is that MFC has a better foundation for solving these problems. It already does the same things as traditional software compilers, so the easy cases should already be handled. I suspect the global transforms will still be difficult but perhaps there's some good prior art in MLIR already. For the problem of custom annotations and transforms, I think MFC is able to define the problem away. Since annotations will be custom MLIR dialects instead of arbitrary data, it should be possible to basically turn that problem into the same problem as the global transform problem.

TLDR: In short, I don't think there's anything we really should do in SFC here, rather we should try to get this solved in MFC.

[ekiwi]

I agree 100% that incremental compilation is out-of-scope for the research compiler. MFC is (hopefully) the way to go.