> The way GHC currently compiles is to first reduce Haskell to a Core language, which is a minimal subset of Haskell, in some sense.
GHC Core is not a subset of Haskell, it's just a simplification of it. The same thing but explained with fewer words (constructors).
That being said, we completely agree that Spineless Tagless G-Machine is full of badassery. Just imagine being able to reduce any Haskell app to, like, 8 different instructions. Something about that fascinates me, even though I'm not quite sure what it is.
> Just imagine being able to reduce any Haskell app to, like, 8 different instructions.
It's a universal property of all programming languages that they can be reduced to a language with just one instruction, so it isn't a surprising result.
How badly does the function pointer technique effect interprocedural optimization? Since LLVM would know the exact control flow it should be able to do the optimisations anyway?
That match(int) technique seems naïve. How would you handle the function arguments/application. The size of the function would also, presumably, large enough to be either very bad for one's icache or requiring more optimisation, which on the assumption that my previous paragraph is correct would make this a wasted effort?
As a person starting to learn Haskell I only understood the steps to Machine code and that you want to cut down the intermediate steps (to C-- step) and go directly to LLVM. If it makes Haskell better you have my best wishes. Haskell is one of those languages that gets less attention that it deserves.
The only type information I can think of is invariants from type definitions and their use (e.g. this ADT contains an Integer that is never less than 5). This information can be used to (say) constant fold branches. This information would have to be reinferred by the optimiser. However, I don't think this would do anything because AFAIK LLVM can already get infer this.
This could give a speed boost: LLVM has llvm.assume with which one can annotate IR with, using this would mean that the optimizer doesn't have to infer this (and therefore save time).
GHC Core is not a subset of Haskell, it's just a simplification of it. The same thing but explained with fewer words (constructors).
That being said, we completely agree that Spineless Tagless G-Machine is full of badassery. Just imagine being able to reduce any Haskell app to, like, 8 different instructions. Something about that fascinates me, even though I'm not quite sure what it is.