3 ms·

> A single IR with multiple passes is a good way to build a compiler https://mlir.llvm.org/ https://mlir.llvm.org/, which is using, is largely claiming the opp

> A single IR with multiple passes is a good way to build a compiler https://mlir.llvm.org/ https://mlir.llvm.org/, which is using, is largely claiming the opposite. Most passes more naturally are not "a -> a", but "a -> b". data structures and data structures work hand in hand, it is very nice to produce "evidence" for what is done in the output data structure. This is why https://cakeml.org/ https://cakeml.org/, which "can't cheat" with partial functions, has so many IRs! Using just a single IR was historically done for cost-control, the idea being that having many IRs was a disaster in repetitive boilerplate. MLIR seeks to solve that exact problem!

JonChesterfield 3y ago
The chez nanopass was similar, different types representing different invariants on otherwise similar IR as it progresses though a pipeline. MLIR has the same common infrastructure idea below the dialects. There are a lot of engineering compromises in compiler design. Single IR vs multiple is one of the contentious ones, where in the details the single IR is prone to having different properties at different points in the compiler and the multiple IR is prone to having strong common themes. I think a consensus is slowly forming that SSA is the right thing, but even there whether phi instructions or block arguments are better is debated, as is whether to stay in SSA form for machine instruction representation or not. Were the early compilers sometimes based on a single IR? My impression is that they went through a wide variety of different representations tied to particular analysis passes, but I haven't seen early implementations of the industrial toolchains. I would be curious about any references you have for that - the optimal decisions of the past are usually worth reconsidering.
- Ericson2314 3y ago
  > I would be curious about any references you have for that - the optimal decisions of the past are usually worth reconsidering. I am afraid I do not have muchon this. > multiple IR is prone to having strong common themes. I am optimistic that with enough fancy tricks (e.g. more type parameters) we can deduplicate. Fundamentally, I rather be very strict and proactive about totality / modularity / formally enforcing invariant, and more lenient/reactive about duplication. Regressions of the former sort are extremely subtle and require tons of hard thinking to resolve. Regressions of the latter sort are comparatively simply to identify and think about the problem. Seeing the commonalities in a bunch of similar things that we don't yet know how to abstract over it also a great way that practice can inform theory!

JonChesterfield 3y ago

The chez nanopass was similar, different types representing different invariants on otherwise similar IR as it progresses though a pipeline. MLIR has the same common infrastructure idea below the dialects. There are a lot of engineering compromises in compiler design. Single IR vs multiple is one of the contentious ones, where in the details the single IR is prone to having different properties at different points in the compiler and the multiple IR is prone to having strong common themes. I think a consensus is slowly forming that SSA is the right thing, but even there whether phi instructions or block arguments are better is debated, as is whether to stay in SSA form for machine instruction representation or not. Were the early compilers sometimes based on a single IR? My impression is that they went through a wide variety of different representations tied to particular analysis passes, but I haven't seen early implementations of the industrial toolchains. I would be curious about any references you have for that - the optimal decisions of the past are usually worth reconsidering.

Ericson2314 3y ago
> I would be curious about any references you have for that - the optimal decisions of the past are usually worth reconsidering. I am afraid I do not have muchon this. > multiple IR is prone to having strong common themes. I am optimistic that with enough fancy tricks (e.g. more type parameters) we can deduplicate. Fundamentally, I rather be very strict and proactive about totality / modularity / formally enforcing invariant, and more lenient/reactive about duplication. Regressions of the former sort are extremely subtle and require tons of hard thinking to resolve. Regressions of the latter sort are comparatively simply to identify and think about the problem. Seeing the commonalities in a bunch of similar things that we don't yet know how to abstract over it also a great way that practice can inform theory!